[Leka 0]

11 hours ago, HardRock said:

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

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

11 hours ago, RobFPGA said:

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

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

 

 

4 hours ago, Nick_K said:

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

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

Изменено 23 апреля, 2020 пользователем Leka

[Leka 0]

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

Изменено 25 апреля, 2020 пользователем Leka

[dvladim 0]

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

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

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

[HardRock 0]

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

[Leka 0]

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

[RobFPGA 27]

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

6 hours ago, Leka said:

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

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

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

Удачи! Rob.

[HardRock 0]

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

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

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

 

[Maverick_ 15]

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

[RobFPGA 27]

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

18 hours ago, HardRock said:

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

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

Удачи! Rob.

[HardRock 0]

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

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

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

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

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

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

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

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

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

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

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

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

[RobFPGA 27]

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

44 minutes ago, HardRock said:

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

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

У дачи! Rob.

[Джеймс 3]

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 выродился при синтезе в какого-то монстра.

[RobFPGA 27]

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

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

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

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

Удачи! Rob.

[HardRock 0]

7 часов назад, Джеймс сказал:

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

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

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

 

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

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

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

 

[iosifk 3]

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 декодера" не знаю, но возможно что и это тоже можно...