Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[100 poits] Help me with this "Z" propagation in n

Status
Not open for further replies.

kel8157

Full Member level 2
Joined
Nov 14, 2007
Messages
131
Helped
5
Reputation
10
Reaction score
3
Trophy points
1,298
Activity points
2,017
Hi, all

I am using a VHDL testbench and controller, which instantitates a verilog model(non-modifiable). There is an INOUT port. My goal is to make the "Z", "1" or "0" to appear on the signal rom_model.hvlt, without modifying the rom_model.v.

However in NCSIM 08.20-s008, I could only see "U" on the waveform in the testbench, which is not a std_logic value.. And rom_model.hvlt appears unknown.

Attached is the codes and run_sim.csh should run the compilation & simulation.

You may need to modify the cds.lib to include IEEE libs.

Thank you in advance.
:?:

(FYI, in modelsim it's okie)


100 points awarded for the solution!
The rom_model.v shall NOT be modified because it's from client.
:D
 

Help me with this "Z" propagation in ncsim please!

Anyone knows why?
 

Re: [100 poits] Help me with this "Z" propagation

Hi kel8157,

the Cadence tools are very strict. Because your verilog model doesn't set hvlt to 'Z', it could be everything. If you route your enable signals through the hierarchy and use this as an enable inverted to your enable in your tb, this means you set hvlt (the "out"-part of your inout) to 'Z' for hvlt_en = '1' you guarantee, that only one signal drives this tristate signal (in my opinion every inout is a tristate signal, because more than one source can drive this line. so to avoid shorts, only one source is allowed to be active and the other sources have to be Z).
If the hvlt is never driven by the rom, you should set hvlt to an input. :)
I can give you other examples that show, that modelsim is sometimes inaccurate. ;) So I wouldn't rely on this simulation so much ;).

Because source code always says more, I attach the changed code and a waveform.

Hope that helps you a little bit. ;)

regards
 

Re: [100 poits] Help me with this "Z" propagation

sorry I've forgotten to mention that in my case the hvlt signal isn't 'Z' (as can be seen in the wave). This is because I was to lazy to use a second enable-signal. :). If you really want to see a 'Z' you have to use a extra en-signal for the rom hvlt and not the inverted tb-hvlt_en ;)

regards again
 

Re: [100 poits] Help me with this "Z" propagation

ddet2004 said:
Hi kel8157,

the Cadence tools are very strict. Because your verilog model doesn't set hvlt to 'Z', it could be everything. If you route your enable signals through the hierarchy and use this as an enable inverted to your enable in your tb, this means you set hvlt (the "out"-part of your inout) to 'Z' for hvlt_en = '1' you guarantee, that only one signal drives this tristate signal (in my opinion every inout is a tristate signal, because more than one source can drive this line. so to avoid shorts, only one source is allowed to be active and the other sources have to be Z).
If the hvlt is never driven by the rom, you should set hvlt to an input. :)
I can give you other examples that show, that modelsim is sometimes inaccurate. ;) So I wouldn't rely on this simulation so much ;).

Because source code always says more, I attach the changed code and a waveform.

Hope that helps you a little bit. ;)

regards

The original rom_model.v is not nicely coded. Are there better ways instead of hacking the rom_model?
 

Re: [100 poits] Help me with this "Z" propagation

ddet2004 said:
Hi kel8157,

the Cadence tools are very strict. Because your verilog model doesn't set hvlt to 'Z', it could be everything. If you route your enable signals through the hierarchy and use this as an enable inverted to your enable in your tb, this means you set hvlt (the "out"-part of your inout) to 'Z' for hvlt_en = '1' you guarantee, that only one signal drives this tristate signal (in my opinion every inout is a tristate signal, because more than one source can drive this line. so to avoid shorts, only one source is allowed to be active and the other sources have to be Z).
If the hvlt is never driven by the rom, you should set hvlt to an input. :)
I can give you other examples that show, that modelsim is sometimes inaccurate. ;) So I wouldn't rely on this simulation so much ;).

Because source code always says more, I attach the changed code and a waveform.

Hope that helps you a little bit. ;)

regards

Thank you for the effort. And your 100 points..
However there is constraints I forgot to mention, the rom_model shall not be modified becuase it's given by client. Reverting back to the client reflects badly on us. :oops:

I can think of nc_mirror nc_force etc, but the latter only works on static signal.

Are there any hacks which works in the VHDL files or scripts?
 

Re: [100 poits] Help me with this "Z" propagation

hiii, thanks for the points :D
I think we have to distinguish two things:
1st we try to fix the simulation.
2nd we try to think about the practical implementation and the consequences of it.

I've to admit, I'm a friend of the latter point :). I'll try to clarify what I mean.

I think your client has this ROM macro. Because he doesn't want to give you to much details about it, he just gave you a simple model. So I don't know, what's the task of the signal hvlt. Maybe you know, maybe not. But if this port is really an inout port, it'll need (in practical hardware) a driver to drive the output and a second path to listen to the bus. I've attached a sketch showing this. If you haven't an enable signal, the ROM will always drive the bus and you won't see a Z in practise and in simulation. This can be possible, if the buffers are proper sized. In that case this is something like a bus-keeper. But this is difficult to account for in simple digital flow. So assume an enable signal. ;)
Maybe this enable signal is hidden in the parts you removed in the posted example. If there's no enable, maybe the signal won't be really an inout.

I think clarification of the task of hvlt should be the next step.

I'll appreciate, if you can provide me further information, so we can continue this interesting discussion.

regards
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top