Да, все оч плохо.
Ну в смыслп я бы такую статью не публиковал. if(rxIN & rxIdleOUT) begin rxClkCounter <= 0;
здесь вы по сути описываете конечный автомат, а rxIN берете прямо со входа. Соответственно, когда фронт rxIN придет очень близко к фронту клока, rxClkCounter потенциально может принять рандомное значение. На симуляциив RTL вы этого не заметите, а вот в железе будет глючить. Ну или можете поэксперементировать с моделированием нет листа с подключенным Back annotation
if(~nRxResetIN) begin rxReg[8] <= 1'b0; rxIndex <= 4'h9; end else if(~rxIdleOUT) begin rxReg[rxIndex] = rxIN; rxIndex = rxIndex + 1'b1; end
Здесь лучше подойдёт сдвиговый регистр:
`
reg [8:0] rxShReg;
always @(posedge clk ...)
…
if (clr)
rxShReg <= #T 9'h1FF;
else
if (rx_do_shift)
rxShReg <= #T {rxShReg[7:0], rx_in};
`
Если в него же задвигать стартовый бит, то по нулю в txShReg[8] будете ловить конец приёма.
rx_in лучше сделать выходом маожоритарной схемы ((a&b)|(a&c)|(b&c)), где a,b,c — входной сдвиговы регистр. Тогда отфильтруете возможные глитчи на длинных проводах, или косяки, связанные с длинными фронтами.
С отправкой такая же шляпа: txPin = txData[txIndex];
у вас здесь вместо изящненького сдвигового регистра, мультиплексор на 8 входов и еще один регистр на выходе. Ничего страшного, если вы пишите UART для макса, но становится страшно за код, который вы родите в более серьезном проекте :)
rxIN счелкать на входе надо, прежде чем отправлять его на вход конечного автомата. А вообще принято triple majority делать.
В делителе считать лучше вниз до нуля. Тогда, когда вы сделаете возможность задавать baud rate регистром, он меньше жрать будет.
Сдивговые регистры тоже красивее смотрятся. Ну и по старт-биту в старшем разряде сдвигового регистра можно определять конец приёма. С передачей счётчик нужен, так уж и быть.
Ну и раз уж статью делайте, то где поддержка parity bit, flow control, приёмный и передающий буфера?:)
Есть весьма простое решение — связаться с правообладателем.
Ваши попытки провалились, вероятнее всего, не из-за низкого оборота, а из-за неумения правильно сформулировать запрос.
Кстати, мне кажется есть не закрытая ниша — платформа для продажи прав на использование ТМ/персонажей. Некий интегратор, покупающий права у крупных брендо-держателей, и продающий их мелким игрокам за % с выручки.
На верилоге всегда можно описать схему так, что на выходе получится именно то, что вы планировали с точностью до гейта.
Насчет схемы — согласен, нагляднее. Рекомендую посмотреть в сторону Mentor HDL Designer — позволяет визуализировать верилог файлы в виде абстрактных цифровых схем, заодно экономит время на рисовании автоматов. Всегда его использую, наглядность значительно экономит время на отладке.
На верилоге писать действительно проще.
Приходите на бесплатный семинар — расскажем как.
Да и в век компиляции в железо прямо C-шного кода (Synphony C, Catapult C), рисовать схемы, наверное, неправильно. На дизайн объемом в миллион лутов у вас может вся жизнь уйти.
Бесплатную лицензию на три месяца можно запросить под какой-нибудь проект.
Для этого надо написать на sales@achronix.ru название проекта, данные контактного лица (телефон, e-mail), Реквизиты организации, и возможный потенциал потребления ПЛИС.
Вот здесь вот публиковались сравнительные характеристики на разных типовых задачах: electronix.ru/forum/index.php?showtopic=113298 — но с тех пор уже был один респин и вышла пара новых версий ACE
Как этот закон будет касаться организаций, зарегистрированных вне юрисдикции России? Россия им де-юре ничего запретить не может.
Ну, будем представляться при регистрации жителями Гондураса какого-нибудь. Или Северной Кореи. На всякий случай.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
А их в тюрячку :(
Ну в смыслп я бы такую статью не публиковал.
if(rxIN & rxIdleOUT) begin rxClkCounter <= 0;здесь вы по сути описываете конечный автомат, а rxIN берете прямо со входа. Соответственно, когда фронт rxIN придет очень близко к фронту клока, rxClkCounter потенциально может принять рандомное значение. На симуляциив RTL вы этого не заметите, а вот в железе будет глючить. Ну или можете поэксперементировать с моделированием нет листа с подключенным Back annotation
if(~nRxResetIN) begin rxReg[8] <= 1'b0; rxIndex <= 4'h9; end else if(~rxIdleOUT) begin rxReg[rxIndex] = rxIN; rxIndex = rxIndex + 1'b1; endЗдесь лучше подойдёт сдвиговый регистр:
`
reg [8:0] rxShReg;
always @(posedge clk ...)
…
if (clr)
rxShReg <= #T 9'h1FF;
else
if (rx_do_shift)
rxShReg <= #T {rxShReg[7:0], rx_in};
`
Если в него же задвигать стартовый бит, то по нулю в txShReg[8] будете ловить конец приёма.
rx_in лучше сделать выходом маожоритарной схемы ((a&b)|(a&c)|(b&c)), где a,b,c — входной сдвиговы регистр. Тогда отфильтруете возможные глитчи на длинных проводах, или косяки, связанные с длинными фронтами.
С отправкой такая же шляпа:
txPin = txData[txIndex];у вас здесь вместо изящненького сдвигового регистра, мультиплексор на 8 входов и еще один регистр на выходе. Ничего страшного, если вы пишите UART для макса, но становится страшно за код, который вы родите в более серьезном проекте :)
rxIN счелкать на входе надо, прежде чем отправлять его на вход конечного автомата. А вообще принято triple majority делать.
В делителе считать лучше вниз до нуля. Тогда, когда вы сделаете возможность задавать baud rate регистром, он меньше жрать будет.
Сдивговые регистры тоже красивее смотрятся. Ну и по старт-биту в старшем разряде сдвигового регистра можно определять конец приёма. С передачей счётчик нужен, так уж и быть.
Ну и раз уж статью делайте, то где поддержка parity bit, flow control, приёмный и передающий буфера?:)
Ваши попытки провалились, вероятнее всего, не из-за низкого оборота, а из-за неумения правильно сформулировать запрос.
Кстати, мне кажется есть не закрытая ниша — платформа для продажи прав на использование ТМ/персонажей. Некий интегратор, покупающий права у крупных брендо-держателей, и продающий их мелким игрокам за % с выручки.
Насчет схемы — согласен, нагляднее. Рекомендую посмотреть в сторону Mentor HDL Designer — позволяет визуализировать верилог файлы в виде абстрактных цифровых схем, заодно экономит время на рисовании автоматов. Всегда его использую, наглядность значительно экономит время на отладке.
Приходите на бесплатный семинар — расскажем как.
Да и в век компиляции в железо прямо C-шного кода (Synphony C, Catapult C), рисовать схемы, наверное, неправильно. На дизайн объемом в миллион лутов у вас может вся жизнь уйти.
Для этого надо написать на sales@achronix.ru название проекта, данные контактного лица (телефон, e-mail), Реквизиты организации, и возможный потенциал потребления ПЛИС.
Ну, будем представляться при регистрации жителями Гондураса какого-нибудь. Или Северной Кореи. На всякий случай.