So, I now have re-coded my model to use guarded ports for the switch model (as per Florent’s suggestion). The code is included at the end of this Email for you to peruse. The good news is that it appears to work a lot better than the original code (driving ‘Z’). However, it doesn’t work with switch instances connected in series. My thoughts originally were that the disconnection of the ports was not generating a transaction to the other instances. I have actually bodged this now to drive ‘Z’ onto both ports before disconnecting, generating a transaction and forcing the other instances to react. I can now get the model to work through 4 switches, but it does seem a little bit messy. So, questions that arose in my mind are: Does the disconnection of a guarded signal generate a transaction? If not can we change ‘TRANSACTION attribute to accommodate this or should we have a new attribute for this function? Then I consulted my copy of Peter Ashenden’s VHDL bible – shock, horror, guarded ports do not disconnect! (This threw me with regard to how I thought that the model was working.) But he does infer that there has been some discussion in the past as to whether or not they should be allowed to disconnect. I would vote yes for this kind of modelling but has anyone else come across this before? At first I thought that this would be a good mechanism for the behaviour of the bidirectional operator (<=>) but now I am not so sure. Regards, Brent ---- <html> <font face="new courier"> <pre> > LIBRARY ieee; > USE ieee.std_logic_1164.ALL; > > ENTITY fst3245_bfm > IS > PORT( > oe_ni : IN STD_LOGIC; > a_io : INOUT STD_LOGIC BUS; > b_io : INOUT STD_LOGIC BUS > ); > END ENTITY fst3245_bfm; > > ARCHITECTURE bfm OF fst3245_bfm > IS > SIGNAL connected_bs : BOOLEAN; > SIGNAL resolved_s : STD_LOGIC; > > BEGIN > > switch_blk : BLOCK (connected_bs) > IS > BEGIN > a_io <= GUARDED resolved_s; > b_io <= GUARDED resolved_s; > > END BLOCK switch_blk; > > switch_proc : PROCESS > IS > -- check for changes in real time > VARIABLE time_tv : TIME := NOW; > > BEGIN > IF (oe_ni = '0') > THEN > -- > -- Set ports to tristate in order to determine external driven values > -- > connected_bs <= FALSE; > WAIT FOR 0 ns; > WAIT FOR 0 ns; > > -- > -- resolve the port driving values and then loop whilst continuously > -- setting the port drivers to the resolved value through chain length > -- > resolved_s <= RESOLVED((a_io, b_io)); > WAIT FOR 0 ns; > WAIT FOR 0 ns; > > WHILE ( (a_io /= resolved_s) > OR (b_io /= resolved_s)) > LOOP > connected_bs <= TRUE; > WAIT FOR 0 ns; > WAIT FOR 0 ns; > > END LOOP; > > WAIT > ON oe_ni, > a_io'TRANSACTION, > b_io'TRANSACTION > UNTIL ( ( (a_io /= b_io) > AND (time_tv /= NOW)) > OR (oe_ni = '1')); > > time_tv := NOW; > > ELSE > connected_bs <= FALSE; > > WAIT ON oe_ni; > > END IF; > END PROCESS switch_proc; > END ARCHITECTURE bfm;</pre> </font> </html> -- 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 Thu Mar 20 01:42:40 2014
This archive was generated by hypermail 2.1.8 : Thu Mar 20 2014 - 01:45:06 PDT