ViKo

Взглянул на свои ACEX1K30. Есть разница в корпусах - те же маркировочные углубления - разное количество, углы - в одной одинаковые, в другой - разные, гравировка разная - шрифт другой, расположение строк... "Не ссы, браток" (с) ДДТ.

Около первой ноги угол больше скошен (может быть).

нужно <<3

module TestSelect (input wire rst_n, clk, input wire [2:0] switch, input wire [63:0] din, output logic [7:0] dout); always_ff @(negedge rst_n, posedge clk) if (!rst_n) dout <= 0; else dout <= din[8*switch+:8]; endmodule

Сделал. В настройках Quartus в NativeLink settings пришлось повозиться. Получается, для теста нужно создавать отдельный файл. Или можно все в одном держать? Картинка, однако, отличается от Quartus'а. Мне, по-прежнему, больше нравится Quartus'овая. А для функциональной симуляции я обычно уменьшал тактовую частоту на порядок, тогда и задержки незаметны. Upd. Уж не знаю, в чем было дело раньше, но сейчас картинки из Quartus'а и ModelSim'а совпадают. Меня это радует.

Спасибо! Ваш пример прошел. Буду разбираться.

RTL симуляцию я задавал непосредственно в ModelSim. Вернее, никакой не задавал. Создал проект, скомпилировал файл, запустил симуляцию.

6 часов - для победы в конкурсе хватит! :)

Подскажите последовательность действий на примере моего кода из сообщения №37. Хочу провести Gate Level Simulation из Quartus'а в ModelSim Altera Starter Edition. Если выбираю Top-Level модуль Test, Quartus ругается: Error: Can't synthesize current design -- Top partition does not contain any logic Если выбираю модуль TestGlitch, тогда не будет вырабатываться сигнал clk для симуляции. Его, наверное, можно нарисовать в Wave. Не пробовал, мне кажется, это - неправильный путь. А как надо? И еще библиотеки - что-то они не подключаются автоматически в ModelSim. Казалось бы - есть в меню EDA Gate Level Simulation. Выбрал, и - поехали. Ан нет.

Ничего не понял. Ни про транзисторы короткозамкнутые, ни про двигатель на холостом ходу. Есть аккумулятор, в котором энергии запасено столько, что может двигатель провернуть, и не раз. Когда машина заводится. Обмотки реле что-то потребляют. Но явно намного меньше двигателя :). Даже 40 штук. Нагрузка, которую коммутируют реле - кто знает, что там. Светодиоды? ... Можно сделать без реле? На транзисторных ключах? - Запросто. Только, похоже, уже поздно.

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

Так я и не говорю, что это что-то экстраординарное. Привел как "среднестатистический" пример. А в памяти у меня тоже, вроде, один из блоков не полностью использовался.

Мои эксперименты показали, что достаточно задать __attribute__((bitband)), и никакого конкретного размещения с помощью __attribute__((at())) не требуется. Ох, и наставили скобок разработчики...

Я уже сам проверил. Теперь двигаюсь по направлению, полученному от "волшебного пенделя" CaPpuCcino :) Только без палок.

Компилятор Keil :) объявить-то можно, но обращаться к ним методом bit-band компилятор не будет. Только к однобитовым полям в структуре. Которая, кстати, не обязательно должна состоять из однобитовых полей, можно иметь и любые другие типы, и int32_t, естественно. К остальным членам структуры будет обычное обращение по адресам bit-band региона. А к однобитовым - по адресам из bit-band alias региона. Скорее всего, такое ограничение введено, чтобы ограничить доступ к переменной единственно возможным способом. Видимо, так компилятору "легче жить".

А мне так не очень понятно, чем могло помешать объединение битов и int для bit-band операций.

Нельзя. В DUI0205I_rvct_comp_user_guide.pdf для bit-band написано: The following restrictions apply: • Bit-banding can only be used with struct types. Any union type or other aggregate type with a union as a member cannot be bit-banded. • Members of structs cannot be bit-banded individually. • Bit-banded accesses are generated only for single-bit bitfields. • Bit-banded accesses are not generated for const objects, pointers, and local objects.

"упростил" :) typedef struct { int b00:1, b01:1, b02:1, b03:1, b04:1, b05:1, b06:1, b07:1; int b08:1, b09:1, b10:1, b11:1, b12:1, b13:1, b14:1, b15:1; int b16:1, b17:1, b18:1, b19:1, b20:1, b21:1, b22:1, b23:1; int b24:1, b25:1, b26:1, b27:1, b28:1, b29:1, b30:1, b31:1; } b_t __attribute__((bitband));

Общение на форуме подталкивает к изучению круче всего. А "замкнутый круг" - я думаю, так есть и будет. "И вновь ему с утра - вставай, учи и снова расставайся" (так, вроде). А поиск на электрониксе, мягко говоря, слабый. Транспортные и инерционные задержки помню. Я предполагал, что ModelSim Altera Starter Edition сам знает задержки, ему бы тип ПЛИС задать. А что, по-умолчанию они равны 0? :unsure:

Попробовал сам, на простом примере на SystemVerilog. `timescale 1ns / 1ps /* Проверка симуляции иголок */ module TestGlitch (input wire clk, en, output logic a = 1, b, c); always_ff @(posedge clk) a = !a; always_comb begin b = a & clk; c = a ^ b; end endmodule module Test; logic clk, en, a, b, c; TestGlitch TG(clk, en, a, b, c); initial begin clk = 1; en = 1; end always #5 clk = !clk; endmodule Да, иголки - абстрактные. В таком случае вопрос - могу ли я каким-то образом просимулировать реальные задержки, как это могу сделать в Quartus? См. картинки - какая вам нравится больше?

А может Rundll показать сильно растянутый во времени фрагмент с "иголкой" из своей картинки из поста №1. Хотелось бы понять, это абстрактные дельта-импульсы или глитчи с конкретной длительностью.

Для работы с битами переменных способом bit-band в Cortex-M3 можно использовать структуру, где биты описаны в виде однобитовых полей. Например, так: typedef struct { int b0: 1; int b1: 1; int b2: 1; int b3: 1; ... } bb_t __attribute__((bitband)); Можно ли заменить описание этих полей массивом внутри структуры, чтобы не набирать вручную все 32 бита?

prt_data_next у вас - выход комбинационной логики? (или триггера? я плохо разбираюсь в VHDL, но этот сигнал, кажется, описан, как регистр). Тогда получается что триггер prt_data_reg по тактовому фронту регистрирует данные в виде глитча. Как насчет удовлетворения временам установления/удержания сигнала? Вероятны метастабильные состояния. Только благодаря тому, что сигнал в комбинационной логике формируется уже после тактового сигнала, можно надеяться на удовлетворение упомянутым временам. Для надежности можно задержать prt_data_next в LCELL. upd. С другой стороны, все сдвиговые регистры так работают, и ничего! Снимаю свое замечание.

Я думаю, у автора темы сигнал upper_code_generator вырабатывается чуть позже, чем shift_register_msb, оттого и глитчи на prt_data_next. А если сделать задержку наоборот - в других местах появятся глитчи. Никаких абстракций. Суровая реальность. xor не прощает несовпадений :)

Да ну его в Висту, квартус такой! Есть 9.1 SP2, и хватит.