Xilinx/ModelSim bug ? Clocking headache ...

model)

A concurrent assignment statement (unlike a port assignment), is not like an alias. Concurrent assignment statements are implied processes with a sensitivity list made up of all signals on the RHS of the assignment. So, they would incur a delta delay for the assignment as well.

Andy

well, that sucks ... For normal signals that doesn't matter much but for clock I'd like a way to force a "zero delta assigment".

Basically at several place I have a "GENERIC" that tells me either to be synchronous or not. If it's true, all of my block will run at clk_1 and instanciate a synchronous fifo. When it's false, part of the process are clocked on clk_2 and I instanciate a async FIFO.

Something like :

---- CUT ----

port ( ... ... clk_1 : in std_logic; clk_1 : in std_logic; ... );

...

signal clk_i : std_logic;

sync: if SYNC generate

-- Assign clock clk_i

I just noticed I didn't even mention what Xilinx had to do with that ;)

In the BRAM simulation model, they do such a clock assignement :

clk_wire

Then don't declare the signal clk_wire. Just use clk everywhere.

-- Mike Treseler

Yes, but I can't do that in every case :

- In one case, this is _inside_ the Xilinx Unisim library ... - In another case, I want to be able to select one clock or another depending on a GENERIC. - Finally in another case I want to export an interface (in a port), where the sub block exports the clk. like :

port ( video_out_data : out std_logic_vector(24 downto 0); video_out_en : out std_logic; video_out_clk : out std_logic; );

For this case, I can probably solve the issue by making video_out_data and video_out_en first in some internal signals, then assign them to the output port. For the other cases, that's a whole lot harder ... And I don't find this behavior correct, because it's pretty far from what the real hw do ... IMHO direct assigments (without operation) should be handled as having no delta delay. And maybe force a way to have one (like after 1 delta).

Or _at_least_ offer some way to force a zero delta assignement .... like clk_1

by 1 delta).

whole thing weird.

It's a standard source of unexpected behaviour in zero-delay VHDL models, and one of the very few reasons why I sometimes prefer Verilog for behavioural modelling - you can do zero-delay combinational signal assignment in Verilog.

I don't understand what's going on in your Xilinx models. I can't believe they put out code that doesn't work with zero delays. You can be fairly sure it will work correctly when all the non-zero (post place-and-route) delays are backannotated into it.

If you're desperate, introduce a tiny non-zero delay in all input signals except the clock, by copying them with a delay:

port_signal

I wish that too now ...

But they did ...

Here's a test case :

Basically cnt, cnt_d1, cnt_d2 and cnt_d3 are connected to the BRAM Data In. And they are assignement one of another :

cnt_d1 input signals except the clock, by copying them with a delay:

Yes that sucks _big_time_

Sylvain

They do. So did micron with their sdram models.

Or make a delayed clock for the pseudo-zero-delay models.

This is one reason I stick to synchronous functional simulation and I leave the timing to STA.

-- Mike Treseler

Instead of wrapping the clk_i assignments in generate statements, wrap the my_sublock instantiation in two generate statements, one with clk_1, and one with clk_2.

Maybe not the solution you were looking for, but it will work.

Andy

|> Instead of wrapping the clk_i assignments in generate statements, wrap |> the my_sublock instantiation in two generate statements, one with |> clk_1, and one with clk_2. |> |> Maybe not the solution you were looking for, but it will work.

This leads to the question how to generally handle it. I had similar problems a while ago by combining bus signals into a record along with its bus clock, so everything is nicely encapsulated. But it doesn't work with the clock when assigning the individual clock to the bus-record at higher levels. So the bus clock must be treated separately in the component instantiation. And the abstraction says good bye...

I can't believe that there is no cleanVHDL equivalent to a pure wire in a schematic...

This does seem strange, but note that this lack of zero-delay wire is only a "problem" for interfacing to models that chain combinational signal assignments inside a process or otherwise skew the simulation clock.

There are many ways to get this right. Mine is to use signals only in purely structural entities.

-- Mike Treseler

Could it be their way of making sure designers pay special attention to avoiding clock skew?

:-)

- Brian

Mike, given that Xilinx did not do this in the unisim package, what do you consider to be the cleanest way to verify functional code that interfaces with these badly written (IMHO) models? Inserting delays on signals, that the synthesis tool is later going to ignore, seems like a horrible band-aid.

Does it make any difference to the simulation tool if the primitives are instantiated in parallel with a functional module within a higher level structural module, versus being instantiated within an otherwise functional module?

Regards, Erik.

My choice is to write my own code that can be used directly for synthesis and simulation. If I instance a vendor netlist to "save time" I have no choice but to make due, somehow, with the vendor sim model.

I don't simulate primitives, just code. I use STA to verify timing.

-- Mike Treseler