Hi Florent, I think you're correct with regard to disconnecting the ports, in fact using guarded blocks and signals is the right way to go for generic type disconnection in the module. However, the main problem is handling deltas and knowing when everything has propagated through, however many delta cycles are required, by a given model in its simulation environment. Your message didn't arrive on the reflector and so I've copied this back to it. Cheers, Brent. On 10/03/2014 07:29, Florent Ouchet wrote: > (off the VHDL mailing list) > > Dear Brent, > > I've seen your message about switch behavior model in VHDL. Isn't something > that can be straight-forwardly implemented using guarded blocks and > connected/disconnected signals? > > Cheers, > > - Florent Ouchet > > Le 09/03/2014 23:57, Brent Hayhoe a écrit : >> I would like to propose a new attribute: >> >> ‘NMD_ATIT >> >> 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 >> <http://tech.yanto-flora.net/e-090424-172201_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. >> >> >> > -- 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: Brent.Hayhoe@Aftonroy.com 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.Received on Mon Mar 10 17:09:28 2014
This archive was generated by hypermail 2.1.8 : Mon Mar 10 2014 - 17:10:03 PDT