RE: [vhdl-200x] Switch model

From: Jakko Verhallen <>
Date: Mon Mar 10 2014 - 01:20:13 PDT
Hi Brent,

What you actually want is a bidirectional assignment (for any resolved type).

The problem with the code you listed below, is that you cannot have 2 of those assignments in a row, it will lead to wrong results.

If you could assign 2 ways (like tran or tranif), then the problem is solved.

I'd like to see something like

a <=> b [when c else 'Z'];

This would ease multiport wires with bidirectional (and conditional) assignments.


From: [] on behalf of Brent Hayhoe []
Sent: 09 March 2014 23:57
Subject: [vhdl-200x] Switch model

I would like to propose a new attribute:


When I first started learning VHDL, there was a conundrum set:

“Build a two port model of a wire with no inferred deltas”

which of course is impossible.

However, we can model wires and more importantly, switches. Recently I had cause
to build a switch model for my test environment which I managed thanks to a
posting by Yanto Suryono:

VHDL Switch Model <>

which includes code by Ben Cohen, in turn modified by Ralf Hildebrandt.

The basics are as follows; given a two bidirectional port entity, first
disconnect the ports (a & b) in order to identify their external resolved
driving values.

a <= ‘Z’;

b <= ‘Z’;

wait for 0 ns; -- wait for one delta period

The next step is to resolve these values into a variable and drive the value
back out on both ports.

c := resolved((a, b));

a <= c;

b <= c;

wait for 0 ns; -- wait for one delta period

This appears like it should work, except it doesn’t and in my case the best I
could attain on the ports was ‘X’ and the worst ‘U’.

The reason for this is that it takes more than one delta cycle for the ports to
stabilize and more importantly it is dependent on the simulation model in which
you instantiate your switch(es).

Next the addition of the ‘chain length’ term to take account of your
simulation’s path through other delta cycle generating assignments.

Both phases above need to looped for twice the chain length. In my case I had to
set this to 3 giving 2 loops of 2x3 delta cycle delays. It does seem like a lot
but the model now works.

The problem I have is that the model now has become application specific to its
simulation environment and there doesn't’t appear to be any way to automatically
check whether these paths have stabilized.

And this leads me to my request for a new attribute ‘NMD_ATIT or “No More Deltas
– About To Increment Time’.

This would generate an event when the simulator determines that there are no
further activities in the current simulation. This could be used for each of the
two steps in the switch model guaranteeing stable resolved values on its ports.

There are questions arising from this e.g. what do we attach it to or more
precisely to what do we decorate it? Perhaps the NOW function? (NOW‘NMD_ATIT).

So simulation experts, reasons why we can or cannot have this attribute?

Best regards,




         Brent Hayhoe.

Aftonroy Limited                            Telephone: +44 (0)20-8449-1852
135 Lancaster Road,
New Barnet,                                    Mobile: +44 (0)79-6647-2574
Herts., EN4 8AJ,  U.K.                          Email:

Registered Number: 1744190 England.
Registered Office:

4th Floor, Imperial House,
15 Kingsway,
London, WC2B 6UN, U.K.

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

Please consider the environment before printing this e-mail

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Mar 10 01:20:43 2014

This archive was generated by hypermail 2.1.8 : Mon Mar 10 2014 - 01:21:16 PDT