How to drive record fields from procedure AND testbench?

Joe, Initialize the record element to 'Z'.

Step 1 declare the following constant after the place in the package where you declare "rec":

constant INIT_REC : rec := ('Z', 'Z', 'Z', (others => 'Z') ;

Step 2 initialize the signal declaration (in the testbench): signal busRec : rec := INIT_REC ;

This is not in books, however, it is in our testbench classes:

In the class we also use a similar technique for our transaction based models. Some details are in the testbench paper at:

Cheers, Jim

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto: snipped-for-privacy@SynthWorks.com SynthWorks Design Inc.

1-503-590-4787

Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

No easy answers. The record direction problem is discussed in this thread:

The signal scope problem is discussed in this thread:

-- Mike Treseler

Hi Mike,

Thanks for the reply. I must be on the right track, because it looks like I have been doing what you suggested in

However, the InitBus call causes compile errors in my design. If I comment out the InitBus call, it compiles fine. (Note that I'm not tackling the inout (tristate) problem at the moment, just the problem of record fields that are either driven from procedures or from the DUT.)

In the thread you cited, no procedure calls are shown, so I'm wondering if this is not possible? Why exactly does my procedure call cause problems with resolution?

I'm wondering if the VHDL standard dictates to not look inside the procedure to check if there really would be a resolution problem. My evidence for this is that even if my procedure contains nothing at all, it still will not compile. When the procedure is empty, in my mind it should be the the same as not having the procedure present at all (a case which compiles fine). Strange. Is the prototype for the InitBus procedure correct for a record that is driven in and out of the procedure?

Another way for the compile to succeed is to remove the driving of rec.waitreq, so the problems are hinging on the fact that different fields being driven from different sources.

prototype:

procedure InitBus( signal busRec: inout rec );

architecture:

-- connections wr

You have stumbled onto the procedure scope problem. Re-read that thread and see the lines I added to my example architecture below.

-- Mike Treseler

------------------------------------------------------------ architecture synth of signal_structure is -- note, I changed your type to data in and out signals type DSPIF_type is record DSPaddr : std_logic_vector(23 downto 0); DSPdata_in : std_logic_vector(31 downto 0); DSPdata_out : std_logic_vector(31 downto 0); nDHOLD : std_logic; nDHOLDA : std_logic; nDPAGE : std_logic_vector(3 downto 0); nDSTRB : std_logic; nDBE : std_logic_vector(3 downto 0); nDOE : std_logic; nDWE : std_logic; nDRDY : std_logic; end record;

signal gaggle : DSPIF_type; signal output_enabled : boolean;

------------------------------------------------------------------------------- -- Added proc example in scope procedure InitBus( signal gaggle: inout DSPIF_type ) is begin end InitBus;

------------------------------------------------------------------------------- begin -- wire up signal structure to pins gaggle.DSPaddr

Hi Mike,

Yes I found my problem, and it was unfortunately in a part of my record that I didn't post. In my record, I had a field that was of the physical type time which I was using inside my procedures for certain delays. ie:

type rec is record ... clock_period : time; ... end record;

So while I was assuming a signal-driving issue to be the problem, it was this field (which is still bizarre, because I set this field only once and never write it again, therefore, I would have thought, it could not be a problem). Anyways, I replaced this field with a clock signal which makes more sense now anyways and everything works great, and thanks to yours and Jim's replies, I understand what's going on much better too. I had better post the whole thing the next time I have a problem like this.

-- Pete

-------------------------------------------------------------------------------

Peter, You can convert time to std_logic_vector by converting it to integer first:

i_int physical type time which I was using inside my procedures for certain

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Peter, As a PS to my other post, to date I have found that if I want to work with a single record, I have been limited to std_logic family.

I have tried tinkering with integers and resolution functions, but have had problems with resolving a value to drive when the record field is not to be driven. It seems that the resolution function is called at the block level and there currently no way I could find to work around this.

This is a topic we are kicking around in the VHDL-200X effort. I had wished for it to be part of the fast track effort and I made a proposal, but it is not clear even to me that the proposal is the best long term solution, so I don't want to push it. My preference is to see what comes up when we give more time and consideration to the problem.

For more on the vhdl-200x effort, see:

IEEE standards are open to public participation.

Best Regards, Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hi Jim,

Yes I would love to participate in the VHDL-200X effort. It's nice to see it's open to the non-members. Is there a target release date for VHDL-200X?

This problem of the fields of a record appearing to be resolved as a group, and not individually, is particularly vexing to me. Hopefully I won't have to deal with it in the next VHDL version.

-- Pete

Peter,

VHDL-200X is a multi-phased effort.

The first phase is fast-track. These are critical update items. It is due to have ready for ballot some time this year. Details on this are at:

There are things that will go out with FT that are not on the FT proposal list. These are items from the other groups that are working them as separate issues.

It has been vexing me too. I don't think we will have the solution for fast track, however, it is one of my high priorities so I will be pushing for it making the revision that follows fast track.

Cheers, Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Pete, I'm sure you're aware that Confluence does not have this limitation:

component some_comp *gaggle with local_source external_reference is gaggle.from_here external_reference end

And in the second thread that Mike referenced, the author mentioned partial function applications. As a functional programming language, Confluence has a few forms of partial functions:

system = {my_component _ _ _}

This allows you to instantiate a component with the ports unconnected, then pass around the resulting system to be wired up later.

-Tom

Hi Tom,

Yes I was, I think, a very early adopter of Confluence. I find the language very impressive. Your FFT core on OpenCores is what got me interested in it.

The biggest problem has been convincing my company to consider the tool, which I have so far been unsuccessful with. As is typical, a company adopts certain standards and practices, and the intertia is difficult to overcome. Hopefully someday ...

Not that I'm unhappy with VHDL, in fact as long as I can work with the latest FPGAs with whatever language I think I'll be very happy, but from my tests I can write IP faster in Confluence than VHDL, and the learning curve is shorter.

-- Pete