The LatticeMico32 is a 32-bit Harvard, RISC architecture "soft" microprocessor, available for free with an open IP core licensing agreement. Everything you need is provided, including software development tools and an evaluation board to try out your designs in hardware.

http://www.latticesemi.com/products/intell...036;3Fp$3F

В общем, тот же ниос2, только без крыльев.
Три варианта - Basic, Standard, Full
Периферия Whishbone-совместимая.

Среда разработки Micro System Builder - ну очень на SOPC Builder похож!
http://www.latticesemi.com/products/intell...opmenttools.cfm

хмм а почему в догонку ? альтера тоже открыла исходники ниоса ?
нуно код этого проца поковырять, если он нормальным HDL ем написан, а не структурным на гейт левеле

Открыла, да.
Задаете параметры - и при соответствующей лицензии геренируется нормальный ХДЛ .

Скачал, посмотрел - чистый Verilog. Синтезировать его не пробовал, т.к. пока не было времени.

придеться вспомнить верилог, у меня канал не толстый, все еще тянеться. Но по даташиту, просмотренному по диагонали сильно похож на ниос но вот при 6 уровнях конвейера всего ~80 МГц это странно.

А на LatticeMicro8 кто-нибудь посмотрел?
http://www.latticesemi.com/products/intell...rollermico8.cfm

Интерес (пока чисто академический) - возможен ли перенос LatticeMicro8 на альтеровский MAX II ?
Неприятность заключается в том, что в исходнике используются библиотечные латтисовские компоненты.
Кто-нибудь возьмется за такую задачу?

хмм :
1. есть же ниос16, dspuva16, atiny16 (раздавали на ниос форум), пикоблейз на нормальном ХДЛ.

2. я бы взялся, но свободного времени практически нет, ждать придеться долго (в моих задачах для управления минимум нужно 16 бит).

ниос16 - отстой, занимает много места и под макс2 не заточен
dspuva16 - не знаком с таким. если не сложно, дайте ссылочку (хотя смущает "dsp" в названии)
atiny16 - годится, до документирован из рук вон плохо
пикоблейз - религия не позволяет

Там нормальный, человеческий код. Компоненты - для симуляции.
Самое главное - поправить ОЗУ для регистрового файла и стека.
На уровне синтезатора - переносился на ACEX, дальше не заходил, т.к. я его только щупал.

Для надежности берите verilog версию, т.к. в vhdl был глюк с прерываниями.

OpenUP(an 8-bit CISC fpga-processor)- http://www.dte.eis.uva.es/OpenProjects/OpenUP/index.htm - 8-ми битник
dspuva16(A 16-bit fixed-point DSP Processor for FPGA) - http://www.dte.eis.uva.es/OpenProjects/OpenDSP/index.htm

А я чего то уже наелся синтезируемыми процессорами, microblaze в частности. Как ни крути, тормоз получатся с большим потреблением, выигрыш от гибкости и возможной железячной акселерации фукций с лихвой съедается временем на отладку подобных вещей.

Вспоминая наш с вами давний спор, вы говорили о микроблейзе по другому.
но все же иногда процы сильно облегачают жизнь, т.к. КА не выход. (особенно если не нужна сверхбыстрая математика, а нужно например расчитав базовый адресс, инициализировать несколько каналов ДМА)

Предлаю всем форумом написать один 16/32 бита риск к нему на эклипсе иде и пользовать его, что бы "патроны блокам подностить" (с) yes с форума сахары

наработки в этой области есть.

Мне вот интересно, какую тактовую системную частоту можно достичь с NIOS-ом на втором циклоне, скажем для системы: CPU(из приблуд только кеш инструкций и данных), SDRAM, UART(несколько), Ethernet. И какая латентность на шине будет.

Система в составе :
- процессорное ядро NiosII Fast с кэшами инструкций и данных и отладочным JTAG-модулем;
- контроллер SDRAM (8 мегабайт);
- интерфейс с внешним Flash-ПЗУ (2 магабайта);
- два UARTa;
- Ethernet 10/100 MAC (использовалось IP-ядро фирмы SLS)
Синтезировалась под EP2C8F256, испоьзовалась SMART-компиляция, оптимизация по занимаемой площади, задана тактовая частота 120 МГц.

В кристалле EP2C8F256C6 занимает 6496 логических элементов (сколько встроенной памяти - пардон, запамятовал). Тактовая частота 138,66 МГц.

В кристалле EP2C8F256C8 занимает 6800 логических элементов, 79360 бит встроенного ОЗУ (примерно 20 блоков M4K). Тактовая частота 93,48 МГц.

(отладочный JTAG-модуль занимает 300-400 LE и 2 блока M4K).

По уму, наверное, надо было бы констрейны для обоих вариантов разные задавать.

Латентность на шине не оценивал.

Не плохо, на спартане3 без секса больше 50~60МГц получить сложно (по крайней мере с мои набором периферии), я не вдавался в анализ того с кокой корки (или каких других факторов) влазит тормоз, но происходит примерно так: по началу, когда проц и пара корок, все разводится на ~100M, потом по ходу приходится уменьшать до 80 и в итоге получаешь 50 .

А сколько унего ступеней конвейера, и сколько тактов уходит на доступ по внутренней шине до корки?
Еще, я так понял, синтезировать можно любым синтезатором?

[quote name='des00' date='Sep 29 2006, 16:14' post='159478']
[quote name='3.14' post='159475' date='Sep 29 2006, 08:09']
cut

Предлаю всем форумом написать один 16/32 бита риск к нему на эклипсе иде и пользовать его, что бы "патроны блокам подностить" (с) yes с форума сахары

наработки в этой области есть.


[/quote]

Приветствую Всех!

Я тоже готов поучаствовать в процессе создания велосипеда :-). Написать корку вобщем то не проблема. Главное обеспечит ее соответствующими КАЧЕСТВЕННЫМИ инструментами (легко адаптируемыми к конкретной архитектуре)- как минимум - компилятор С симулятор/эмулятор. Именно это (по мойму) и есть главная проблема в softprocessor строительстве. Я в течении месяца провел маленькое исследование в этой части и результаты не очень радостные - из возможных претендентов на компилятор ( если не разрабатывать с нуля) - LCC, SDCC, и GCC. LCC -прост в модификации под конкретный процессор но почти отсуствует оптимизация.
GCC - имеет хорошую оптимизацию но требует большой объем работы при модификации, SDCC - занимает промежуточное положение. Привязка же под конкретный софт/архитектуру процессора неизбежно влечет избыточность на аппаратном уровне но позволяет не ломать голову на софтварном.

Удачи! Rob.

У меня в одном из проектов (правда без софтпроцессора) наблюдалась подобная ситуация. Очень помог PlanAhead. Рекомендую попробовать...

[quote name='RobFPGA' date='Sep 30 2006, 14:08' post='159691']
[quote name='des00' date='Sep 29 2006, 16:14' post='159478']
[quote name='3.14' post='159475' date='Sep 29 2006, 08:09']
cut

Предлаю всем форумом написать один 16/32 бита риск к нему на эклипсе иде и пользовать его, что бы "патроны блокам подностить" (с) yes с форума сахары

наработки в этой области есть.


[/quote]

Приветствую Всех!

Я тоже готов поучаствовать в процессе создания велосипеда :-). Написать корку вобщем то не проблема. Главное обеспечит ее соответствующими КАЧЕСТВЕННЫМИ инструментами (легко адаптируемыми к конкретной архитектуре)- как минимум - компилятор С симулятор/эмулятор. Именно это (по мойму) и есть главная проблема в softprocessor строительстве. Я в течении месяца провел маленькое исследование в этой части и результаты не очень радостные - из возможных претендентов на компилятор ( если не разрабатывать с нуля) - LCC, SDCC, и GCC. LCC -прост в модификации под конкретный процессор но почти отсуствует оптимизация.
GCC - имеет хорошую оптимизацию но требует большой объем работы при модификации, SDCC - занимает промежуточное положение. Привязка же под конкретный софт/архитектуру процессора неизбежно влечет избыточность на аппаратном уровне но позволяет не ломать голову на софтварном.

Удачи! Rob.
[/quote]

Участвовать можно даже в озеленении Луны. Но перед началом проекта нелохо задаться парой-тройкой вопроов о том что же собственно делаем:

1. Это обычный проц или DSP?
2. Заточен в основном для FPGA или ASIC?
3. Какие изюминки архитектуры(регистровые окна например)?

ну и так далее, список может быть довольно длинный.

Так вот на мой непросвещенный взгляд ответы будущих пользователей этого чуда могут оказаться весьма противоречивыми.

К стати один из самых больных вопросов это действительно всякие компиляторы ибо чем сложнее и извращенней ахитектура проца тем больше надо возиться со всякими гнусными оптимизаторами и т.д.

2 klop и RobFPGA

Если вам интересно мое ИМХО, то я считаю что разрабатывать :



не имеет никакого смысла, т.к. в этом случае мы лишаемся основной фичи ФПГА- множественного параллелизма. Даже мульти векторность АЛУ не спасет, т.к. это только приведет к усложнению проца -> падению тактовой частоты и/или увеличению задержек.

Есть много обычных процев как заточенных под фпга (ниос, микроблейз, мико32) так не сильно заточеных под фпга, есть даже синтезируемые модели дсп процессоров. И под них есть и компиляторы, симуляторы, дебагеры. Но все это нето.

самое то разработать процессор,

1. с поддержкой сложных переходов (как в КА), особенно что касается обработки входных пинов.
2. расширеными возможностями интерконнекта с другими объектами (быстрые порты ввода/вывода, аппаратная поддержка шинных интерфейсов (механизма handshake), отмапливание внешних, относительно проца регистров на регистровый файл и т.д.)
3. с простым АЛУ общего назначения средней производительности (всякие адреса считать и т.д.)
4. и возможность добавить АЛУ специального назначения, на несколько комманд.

наворотов для математики в этом проце не нужно, т.к. вокруг "море" логики, на которой можно считать, но которой нужно управлять.

и утоптать все это в 200-300 плиток, и хотя бы 266-300 МГц виртекса5/4 и стратикса2

Ну а программу для такого управляющего проца, можно и на асме написать. Писали же под атмеги85хх 8 к кода на асме . Да и при граммотном разбиении задачи на блоки, больше чем 2к памяти программ потребуется очень редко.


ЗЫ. можно пойдти еще дальше, если есь подобный проц, то взяв несколько этих процев, сваять из них вычислительную цепочку, когда каждый проц пишет и читает в регистровый файл соседа, организованный как double-buffer регистровый файл.
и не будет проблем синхронизации вычислительных блоков, между собой.

Ну то есть енто проц специально для FPGA. Вот и ответ на один из вопросов!

1. NiosII Fast - шестистадийный конвейер, однотактовый перемножитель/сдвигатель (при использовании встроенных перемножителей или DSP-блоков FPGA), динамическое предсказание переходов, конфигурируемые кэши инструкций и данных. И 256 инструкций пользователя (типа создай свою систему комманд ).
2. Какой именно корки? Их в проекте несколько...


Синтезировать квартусом.
Если использовать внешний синтезатор, то NiosII можно вставить как blackbox.
А если есть желание открытый ниосовский hdl-код синтезировать (к примеру, под FPGA других фирм), то нужно врукопашную в исходнике комментарии править (там какая-то квартусовская фича используется - типа рассматривать комментарии как часть исходного текста) - уважаемый vetal про это может подробнее рассказать.

Есть два типа "любителей" софт процессоров:
первые идут "от хард микроконтроллеров" - им плевать на эффективность разработки. Дайте им AVR внутри FPGA и все! Хотим!!! Поэтому фирмы предлагают ядра "похожие" на хард микроконтроллеры. И программировать хотим только на Си. Поскольку код малоэффективный, то его будет много...

вторые, а к таковым я отношу себя и des00, мы идем от железа. Мы готовы сделать набор микроконтроллеров "под заказ", при этом само проектирование будет гораздо сложнее (хотя при известном опыте дело идет довольно быстро) и программировать придется на ассемблере, но в целом такой подход дает более производительный проект, выше тактовые частоты, более легкую аппаратную отладку. А отладка облегчается, тк на специализированном процессоре легче программировать тесты, команд надо довольно мало. Вот в моем предыдущем проекте я сделал связку из 17-ти битового процессора и 1-но битового. В 17-ти битовом было 1КСлов кода (32 чтения 12-ти битного АЦП с накоплением результата). Это примерно в 3-4 раза более эффективно (т.е меньше по объему команд), чем для стандартного. А выделение обработки блокировок для управления примерно 50 шт. реле в отдельный микроконтроллер увеличило эффективность примерно еще на порядок (но это моя субъективная оценка...)

Так что вот два пути...
Ну и соответственно две методики выбора микроконтроллеров.

Имхо, все упрется в программирование, и ассемблер не выход: упор на быстродействие приведет к "длинной" инструкции, ограничения архитектуры FPGA - к вынужденной неортогональности --> проблемы программирования.

хмм, опять же зависит от того, с какой стороны посмотреть.
если под длинной инструкцией вы понимаете програмное слово со слабым кодированием, то это не есть проблема. К тому же 64 бита ширины програмного слова не проблема на фпга.
Не стоит делать у такого проца большое кол-во команд и режимов адресаций, а достаточно заточить его под задачу, помня о назначении проца. Т.е. после написания кода, помочь синтезатору и "поотключать" все неиспользуемые команды. Синтезатор достаточно хорошо минимизирует логику.

Если вы хотите много считать, то сделайте отдельный блок математики и включите его в декодер комманд процессора и/или отмапте на регистровый файл и пару пинов ввода/вывода.

PS. Не обязательно процессор делать однотактным и без конвейера.
PPS. кстати по такому пути пошли Field Programmable Object Array (FPOA) и Ambric и т.д.

PPPS. Декодер потока команд управления, своего StateSeq я как раз и "вырвал" из своего программируемого проца, версии2 (версия2, заимствует идеи интерконекта как раз из FPOA). Посмотрите на StateSeq и вы поймете что я имею в виду, под заточкой под задачу .
http://electronix.ru/forum/index.php?showt...19202&st=15

Первые идут от того что писать серьезные задачи для одного uC нескольким людям реально при наличии OS, C компилера ну и т.д. Иначе ничего путного не получишь. Никто не говорит что второй путь плох. Просто скорее всего для получения результата надо их комбинировать.

Под длинной инструкцией понимаю несколько операций в одном программном слове. Например: переход + арифметика + пересылка. Свой софт-процессор написал (однотактный, конвейер - 2 стадии). Столкнулся с тем, что неортогональность при длинной инструкции превращает написание программы(на ассемблере) в пытку.

понятно, спасибо за разьяснение.

Один раз я как раз угодил в подобную ловушку, т.е. достаточно сильно переутяжелил логику процессора, в итоге сильно упала тактовая и разработка на асме стала пыткой, т.к. голову сломаешь что да куда. В итоге отказался от такого подхода.

Именно поэтому и обеими руками за упрощение проца + его конфигурируемость. Основное назначение проца - управление и медленная (многотактная математика). Если нужно что то считать быстро - например ДКТ, то пишем корку и мапим регистры дкт на регистры такого проца. На этом его задача заканчиваеться. Нужна выше производительность ? поставим еще проц и будет конвейер.
нужно порулить ДМА и 10 аппаратными блоками по AMBA вообще не имплементим математику, только адреса считать.

Имхо. Одна из главных проблем софт-процессора: "правильный" многопортовый регистровый файл с асинхронным чтением. Блочная память не допускает асинхронное чтение, распределенная - многопортовую запись. Обход этого ограничения выливается либо в неортогональность системы команд, либо к дополнительным тактам/ступеням/логике(+задержке).

LatticeMico32


http://www.latticesemi.com/dynamic/index.c...=01-01-08-11-48

tam verilog RTL, eclipse based SoC design env, + GCC C compiler (s ishodnikami)

bus sistema Wishbone

RTL mozhno i v xilinx ispolsovat, tut malenki project - rabotaet ok v Virtex-4,proveril

http://www.microfpga.com/joomla/index.php?...leinfo&id=2

mozhno s ISE ISIM simulatorom tozhe simulirovat!

Antti

ja pro LatticeMico32 v drugom forume pisal, nado bylo zdesh ransche posmotret
LM32 6 stupeni konveier

no v standard variante BLOCK RAMs no wishbone sidit i po etomy OCHEN medlenno

sw r0,r0,0x100
bi -1

tokoi loop 28 cyclov berit v BLOCK RAMe !!

dolzno byt mozhno BRAM na CPU direct postavit no GUI eto poka ne poderzivaet

ja dlja ISE maleknki test TOP delal s LatticeMico32, rabotaet!
project sources mozhno kachat tut

http://www.microfpga.com/joomla/index.php?...leinfo&id=2

voobche to interesno!
compiler GCC, istochniki tozhe segodnja na Lattice web postavili

Antti

vetal

вы правы, но даже такая задача решаеться достаточно просто.
1. Честный двухпортовый регистровый файл у ксайлов делаеться на 2-х RAM16D. При этом мы можем читать 4 числа и писать 2 числа. Если не нужен доступ одновременно к 4 м числам, то все еще проще. Нужно использовать 2 однопортовки. Но при таком подходе возникает не возможность отмапливания регистров на внешние устройства.

2. Если требуеться небольшое кол-во регистров, то все просто, можно использовать набор обычных регистров. В этом случае упрощаеться реализация управления внешними устройствами + можно делать распределенную, многобайтную арфиметику.

Можно также сделать составной регистровый файл. часть на памяти, часть на регистрах.

я в програмировании не очень силен, т.к. писал на асме в основном только под х86, AVR, 51, но не могу понять зачем вы хотите именно ортогональную систему комманд, в процессоре специализированного (фпга) применения. Т.е. проц для фпга ИМХО - прежде всего не универсальное решение на все случаи жизни, а уменьшение времени разработки и отладки.


Всем:
Думаю достаточно клаву греть
Если кто-то хочет поучаствовать в разработе подобного проца, то давайте каждый подготовит описание типовых задач, которые он решал/решает в текущее время и выдвинет свои требования к процу. Затем, за несколько on-line встреч (можно в irc), можно обсудить идеи и выработать концепцию проца и стратегии разработки.
А дальше остаеться только определиться с назначением работ по разработке и реализовать, как сам проц, так и софт для разработки на нем.

Здравствуйте, Денис!
Готов участвовать - HDL, "немного" софт , есть скромные наработки. А софт(асм) имхо на перле лучше писать

У меня "красиво" не получилось. True dual port у меня реализуется на 2-х RAM16D и дополнительной логике, но тактовая падает вдвое при 8-кратном росте числа LUT --> теряется всякий смысл. На 2-х однопортвках однотактовый true dual port не реализуется, имхо. Можно примеры?

У меня проект - многоядерный микроконтроллер, с прицелом на перевод в ASIC, отсюда все требования к ядру. Проверка софт-процессора "на вшивость": чисто программная (т.е. без использования каких-либо аппаратных костылей) реализация цветного текстового контроллера VGA (640*480 @25МГц) - задача управления в чистом виде со строгим таймингом. Для 8 цветов у меня с этим справляются 2 ядра(по 300..400 LUT) @50МГц (starter kit spartan3e).

2 Postoroniy_V, Leka, RobFPGA

Извеняюсь за паузу, я предоставлю описание своих задач и видение контроллера после выходных.

Работы много

on-line обсудить все можно будет в irc чате или в конференции. Но думаю что более разумно будет создать отдельную тему

После выходных не получилось работы много навалилось.



да, я реализовывал регистровый файл на 2-х RAM16D + мультиплексоры на выходе, но зная "такую особенность" я реализовывал 3-х стадийный конвейер, отделяя отдельно стадию write back (за счет чего получил простое декодирование условных комманд) поэтому уложился в требования по производительности

Насчет однопортовых true dual port не возможен, но мы же решаем задачу в ограниченном базисе (FPGA), поэтому можно наложить небольшие ограниченя на используемые командами адреса операндов

А можно узнать подробнее про ваше ядро ? интересует система комманд (остальное следует из нее )

Меня же тема процов интересует с точки зрения управления и заворачивания битстрима в NAL unit (т.е. медленной математики), что бы экономить ресурс ФПГА. А для быстрой математики есть обычная логика + ДСП слайсы в помошь

по процу я почти закончил формировать блок-схему, выложу на днях. (постараюсь выкроить время, что бы ее закончить).

Детали раскрывать не хочу - возможно, будет использоваться в коммерческом проекте. Ядро: spartan3e, ~300LUT, гарвардская архитектура, 36-разрядная инструкция, 18-разрядные данные, 2х-ступенчатый конвейер, 1 такт на инструкцию, 1 клок без фаз, ~100МГц (по данным P&R, пока отлаживаю на 50МГц). До 3х операций на инструкцию: условный переход+арифметика+пересылка (память/устройство <--> РОН). Все управление, пуск-останов, загрузка программы - через com-порт. Те с железом и с ассемблером (низкоуровневым компилятором) - проблем у меня нет (пройденный этап). Но - писать на ассемблере очень не понравилось --> хочу ввести элементы языка высокого уровня.

Предлагаю сосредоточится именно на аспекте высокоуровневого программирования,
поскольку железо+ассемблер делается и модифицируется легко и быстро (при наличии опыта, конечно). Те _конкретизировать_ пути получения высокоуровневой среды программирования для _произвольного_ софт-процессора.

Тоже предлагаю выделить в отд.тему:
атачмент -
Идея крайне неплоха

Меня интересует (в контексте):
- дешифратор команд (на чем.... или в зависимости от системы команд)
- конвейер (если их сделать несколько но с малым кол-вом ступеней, разнести по задачам
и отдельно объеденить через рег. окно)
(т.е при повышении кол-ва зан.ресурсов увел. конвеер+ меры по повышению быстродействия)
- прерывания (хотя контроллер прерываний в контексте фпга..., скорее уж механизм прерываний и их уровни)
- стр-ра памяти

... ой чето я увлекся, короче ждем отд. ветку
готов участвовать, думать, т.к. еж таки это моя специальность (выч. системы, комплексы и сети) в чистом виде.

мат. анализ или модель (частично) могу взять на себя

к тому же быстродействие зависит не только от частоты но и организации

Я думаю так:
1. Модель на уровне HDL (+синтезатор)

2. Оптимизация под конкретные плисы(в иделе законстрейтеные)

В таком случае возможно выжать все


>>> to des00 блок-схему бы посмотреть

это очень интересно
помимо уже упомянутого DSPuva16 и заброшенного на этапе АЛУ проекта С5400 (TI) что-нибудь реально есть???

LEON поддерживает SPARC v8e - то есть 32х32 МАС 40бит можно иметь каждый такт при регистровых операндах
если использовать раздельные памяти, то наверно 0.5 МАСа на такт,

upd : про 0.5 МАСа я не подумавши написал, дтя свертки векторов надо
загрузить с индексом один отсчет,
второй,
MAC
декрементировать счетчик
перейти
то есть 5 инструкций, при раздельных шинах и использовании делей-слотов 5 тактов

у меня получалось для спартана 50МНz, для В4 до 100

но так как неоптимизирован "по LUTам" проигрывает по площади блейзу

имхо, самое важное, что есть ГЦЦ (то есть С С++ АДА ФОРТРАН и т.п.)

Народ! Кто уже использует этот проц, просьба поделиться впечатлениями.

А то глядя на среду разработки ispLevel закрадывается сомнение, что проц тоже очень кривой

Процессор как процессор, работает без нареканий. А вот отладчик программистам не нравится. Часто глючит при пошаговой отладке, если есть обращение к аппаратуре (UART, SPI etc.) Если тот же код пробежать по команде Run, то все работает.

сайт изменился :-((
если у кого есть материалы по dspuva16, прошу поделиться - интересно глянуть

Заранее спасибо

Uuftc
как вариант: посмотреть сайт через кэш гугл: http://209.85.135.104/search?q=cache:sOmna...;cd=4&gl=ru (видимо его удалили совсем недавно)

сами исходники: http://www.dte.eis.uva.es/OpenProjects/Ope...00/DSPuva16.zip (но ядро там совсем простенькое)

через кеш гугла смотрел. а вот файлов нет ....

Хорошо. Есть еще пара вопросов.
Вы его на других ПЛИС пробовали? Если да, то как он себя ведет после компиляции (размер кода, тактовая частота)?

Uuftc
Нажмите для просмотра прикрепленного файла

Спасибо.

Нет, на других семействах не пробовал.
А вот у господина antti (можете поискать его сообщения по форуму) получилось запустить mico32 на Virtex-4:
http://www.microfpga.com/joomla/index.php?...leinfo&id=2

ммм. а кроме ядра есть софт для моделирования? можно его сюда же? или он уже в закромах родины?

Mahagam
кэш гугла у вас есть - где там про тестебенчи сказано??
всё предоставляется (цитирую): "as is"

http://www.dte.eis.uva.es/Datos/Congresos/FPGAworld2005a.pdf
вид отладочного софта на предпоследней страничке. вот это бы хотелось увидеть