1. Home
  2. Field-Programmable Gate Arrays
  3. could use some help with verilog/vhdl

could use some help with verilog/vhdl

I'm having a problem with a state machine written in verilog that I need to get into vhdl. My simulation license only allows vhdl and I can't afford one that will do both. The problems is worse because it simulates just fine, but fails Xilinx ppr. But it has also run Xilinx ppr, so I'm thinking it involves the work directory and "cleanup project files" too. Perhaps if I ppr using the verilog file and then switch to the vhdl file it works fine until I "cleanup project files" and the fails from that point on? Anyway, the verilog code:

always @ (CurrentState or count or rxstatus or rxelecidle or rx_locked or align_det or sync_det) begin : SM_mux count_en = 1'b0; NextState = host_comreset; linkup_r = 1'b0; txcomstart_r =1'b0; txcomtype_r = 1'b0; txelecidle_r = 1'b1; send_d10_2_r = 1'b0; send_align_r = 1'b0; rxreset = 1'b0; case (CurrentState) host_comreset : begin if (rx_locked) begin

was replaced with the vhdl code: SM_mux : PROCESS BEGIN

WAIT ON CurrentState, count, rxstatus, rxelecidle, rx_locked, align_det, sync_det;

count_en

Reply to
Dan K
Loading thread data ...

You could have worse problems in store for you. Your verilog and vhdl code may not perform the way you think they will. You have only posted a subset of the code so I can't tell if the difference will bite you now or only in the future when you change your code.

In your verilog code you are use blocking assignments. This means in the future any use of that reg will have the new value that was recently set. In the VHDL your code is assigning signals, signals do not get updated until the process finishes executing. Which means references to those signal names will use the old value for computations not the new value like the verilog code does. A general rule of thumb when converting between vhdlverilog blocking converts to variables and non-blockign converts to signals. This probably isn't an issue right now. You haven't gotten far enough into the process for these difference to show up. They wouldn't show up as an error message. They normally show up as 2-3 days of tearing you hair out trying to figure out why the code isn't working as expected.

You can attempt to bypass your current error by using:

SM_mux : process(CurrentState, count, rxstatus, rxelecidle,rx_locked, align_det, sync_det)

and eliminating the "WAIT ON" line.

it will still be equivalent, but the xilinx software may be getting confused on the "wait" statement and tring to infer flipflops or multiple clocks instead of pure combinational logice. Granted, this is a guess based on the code snippets. The full RTL could get you better answers. You also want to post on the comp.lang.vhdl and comp.lang.verilog news groups. You might get more feed back.

Reply to
Dwayne Dilbeck

Try changing this:

DSM_mux : PROCESS

...

for this:

DSM_mux : PROCESS (CurrentState, count, rxstatus, rxelecidle, rx_locked, align_det, sync_det) BEGIN count_en may not perform the way you think they will. You have only posted a subset

Reply to
PatC

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.