Jump to content

    

Начинаю изучать FPGA (verilog)

11 hours ago, HardRock said:

использование встроенной памяти это больше оптимизация чтобы высвободить место под функционал? 

Да, в первую очередь, чтобы ЛЕ сэкономить. Лучше использовать термин - блочная память, тк м/б несколько видов встроенной памяти. Блочную память лучше описать в отдельном модуле, без какой-либо дополнительной логики, тогда всегда будет синтезироваться, как блочная.

11 hours ago, RobFPGA said:

Если есть возможность обрабатывать во время приема байт-за байтом - то зачем откладывать это в длинный (80 бит)  ящик чтобы потом опять лазить по нему мультиплексорами?  

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

 

 

4 hours ago, Nick_K said:

Полно книг где основная задача именно синтезировать.

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

Edited by Leka

Share this post


Link to post
Share on other sites

Взять, к примеру, разработку устройств на микроконтроллере (stm32 и тп). Отладка - в железе, без какого-либо специального языка верификации, без симуляции на компе. Для ПЛИС тоже надо к этому стремиться. 

Edited by Leka

Share this post


Link to post
Share on other sites
1 час назад, Leka сказал:

Отладка - в железе, без какого-либо специального языка верификации, без симуляции на компе. Для ПЛИС тоже надо к этому стремиться.

Весьма спорное утверждение. Вы бы еще для ASIC тоже самое предложили.

Share this post


Link to post
Share on other sites

Я думаю нужно исходить из задачи и её вводных. Где-то лучше отладка в железе, где-то симуляция. Все это инструменты для достижения более глобальной цели, а инструменты, как известно, лучше работают если их использовать по назначению :) 

Share this post


Link to post
Share on other sites

Для процессоров - куча парадигм программирования ( https://ru.wikipedia.org/wiki/Парадигма_программирования ), а для синтезируемого HDL что - пара костылей из инструментов верификации.

Share this post


Link to post
Share on other sites

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

6 hours ago, Leka said:

Для процессоров - куча парадигм программирования ( https://ru.wikipedia.org/wiki/Парадигма_программирования ), а для синтезируемого HDL что - пара костылей из инструментов верификации.

Ну так все эти парадигмы  вы в полной мере можете применить и для разработки на HDL,  а уж тем более для верификации. 

Только какое отношение имеет эти парадигмы  к инструментам и технологиям разработки? (за исключением что просто красивое слово попалось :biggrin:

Удачи! Rob.

Share this post


Link to post
Share on other sites

Как можно более эффективно сделать коммутацию сигналов по типу каждый с каждым в зависимости от настроек?

Сделал по-программистски, завел вектора сигналов и перекладываю их в каждом клоке. Однако, синтез такого тратит много логических элементов. Как оптимизировать?

always(@posedge clk) begin
  
  ...
  
    // ------------------------------------------
    // - IO Channels commutation logic
    // ------------------------------------------
    for (io_idx = 0; io_idx  < IO_CHANNELS_COUNT; io_idx++) begin
      case (__REG_MEMORY__.io_channels[io_idx].mode) 
        // - Disabled
        'h00: __IO_CHANNELS__[io_idx] = 'bZ;
        
        // - Channel
        'h01: __IO_CHANNELS__[io_idx] = __IO_CHANNELS__[__REG_MEMORY__.io_channels[io_idx].resource];
        
        // - Input :: PWMDecoder
        'h02: __PWM_DECODER_IN_TABLE__[__REG_MEMORY__.io_channels[io_idx].resource] = __IO_CHANNELS__[io_idx];
        
        //'h03:
        
        // - Output :: PWMEncoder
        'h04: __IO_CHANNELS__[io_idx] = __PWM_ENCODER_OUT_TABLE__[__REG_MEMORY__.io_channels[io_idx].resource];
        
        //'h05: 
      endcase
    end
          
end

 

Share this post


Link to post
Share on other sites

Отдельным процессом описать мультиплексор и отдельно описать декодер, который будет управлять комутацией

Share this post


Link to post
Share on other sites

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

18 hours ago, HardRock said:

Сделал по-программистски, завел вектора сигналов и перекладываю их в каждом клоке. Однако, синтез такого тратит много логических элементов. Как оптимизировать?

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

Удачи! Rob.

Share this post


Link to post
Share on other sites

Есть набор выводов плиса. Есть набор приёмников и передатчиков, реализованных в плисе. 

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

Если как вход, то его можно подключить к заданному приемнику. 

Если как выход, то к заданному передатчику либо к другому выходу чтобы дублировал состояние. 

Нужно 32 вывода, соответственно 32 приёмника и передатчика одного типа и штуки 2-4 другого типа. 

На 16 каналов ёмкости плиса хватает. На 32 - превышение почти в 2 раза) 

Рост линейный, но общее потребление велико.

Можно сделать как планировал изначально чтобы к каждому выводу был свой приёмник и передатчик тк их число должно быть равно чтобы обеспечить "все на приём" и "все на передачу". Это должно уменьшить сложность. Пока сделано что вывод назначается, это удобно для пользователя т. к. очень гибко настраивается, но конечно, потребляет элементы. 

Вопрос наверно более концептуальный на тему как лучше делать подобного рода коммутаторы. 

Как это сделать на "корпусах" мультиплексорах и демультиплексорах понимаю, в RTL нечто подобное, но есть ощущение что перерасход элементов. 

Плюс ко всему ещё память не оптимизировал чтобы использовалась блочная, она ещё реализуется синтезатором, и видимо на стыке коммутатора и памяти происходит перерасход. 

Вобщем проект с желаемым функционалом не влазит в желаемый плис пока) 

Share this post


Link to post
Share on other sites

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

44 minutes ago, HardRock said:

опрос наверно более концептуальный на тему как лучше делать подобного рода коммутаторы. 

Вот именно концептуальный - но  любая концепция базируется на жесткой реальности -   какие приемники и передатчики, протокол, макс. скорость,  итд. итп? Если это относительно медленные  скорости то тот  же  коммутатор можно сделать на базе  кольцевых   регистров  на подобии token-ring.   Ну и те же приемники/передатчики можно лепить независимые,  а можно  в виде  автомата состояний последовательно обрабатывающих несколько физ. каналов.  Например тот же SPI с битовой скорость 1MHz , при внутренней тактовой  в 100 MHz можно на одном автомате до 20-50 штук обрабатывать с достаточно-малым джиттером. 

У дачи! Rob.

Share this post


Link to post
Share on other sites
On 5/3/2020 at 7:54 PM, HardRock said:

Нужно 32 вывода, соответственно 32 приёмника и передатчика одного типа и штуки 2-4 другого типа. 

На 16 каналов ёмкости плиса хватает. На 32 - превышение почти в 2 раза

Ээ.. На что-не хватает емкости-то? На 32 контроллера каналов? Или на 32 коммутатора?
Если на 32 контроллера, то чудес не бывает, - надо брать большую плис. (Хотя.. у вас там SPI контроллеры и PWM в самом маленьком Cyclone-4, вроде?). Должны поместиться, но подходы к разработке совершенно другие нужны. Но об этом бесполезно говорить.

Если же не хватает места на коммутаторы, то это наверное шутка. Или ваш цикл for выродился при синтезе в какого-то монстра.

Share this post


Link to post
Share on other sites

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

5 hours ago, Джеймс said:

Если же не хватает места на коммутаторы, то это наверное шутка. Или ваш цикл for выродился при синтезе в какого-то монстра.

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

Удачи! Rob.

Share this post


Link to post
Share on other sites
7 часов назад, Джеймс сказал:

Хотя.. у вас там SPI контроллеры и PWM в самом маленьком Cyclone-4, вроде

1 SPI Slave, 32 PWM генератора, 32 PWM декодера, 4 UART RX / TX с фиксированным рейтом. Коммутация между всем кроме SPI, он отдельно.

Циклон да, самый маленький  - EP4CE6E, такой на девборде распаян, так что пока без вариантов) Да и следующего на 10К ячеек тоже не хватит, а всё что дальше слишком большое физически.

 

1 час назад, RobFPGA сказал:

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

Что-то типа того :)

 

Share this post


Link to post
Share on other sites
1 минуту назад, HardRock сказал:

1 SPI Slave, 32 PWM генератора, 32 PWM декодера, 4 UART RX / TX с фиксированным рейтом. Коммутация между всем кроме SPI, он отдельно.

Я в "кратком курсе", в главе о многопоточности и Rob чуть выше: "Например тот же SPI с битовой скорость 1MHz , при внутренней тактовой  в 100 MHz можно на одном автомате до 20-50 штук обрабатывать с достаточно-малым джиттером. "

Ваши 32 PWM генератора наверняка возможно обмолотить одним автоматом, если к нему добавить немного памяти... Что такое "32 PWM декодера" не знаю, но возможно что и это тоже можно...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now