Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is there still no elegant way to create a BFM with a transaction-level interface?
425 views
Skip to first unread message
Jon Skull
Dec 10, 2014, 6:57:11 AM12/10/14
to
Hi VHDL fans,
I've been slowly taking up the various enhancements provided in VHDL2008, and I find some very useful for testbench construction, particularly generic packages.
However, am I missing something, or is there still no elegant way to create a pin-wiggling BFM driven by a transaction level (procedural) interface?
Verilog has always supported this because it is possible to call a procedure from outside the module in which it is declared.
For years I've approximated this in VHDL by using an inout "transaction" record port on the BFM, with some horrible bidirectional handshaking to transfer the transactions. I then define a package of procedures which take this transaction record as an inout argument. I think other people use this approach too, but it's far from ideal as you are forced to use resolved signal types for all of the record elements.
Has anyone found a better way using (supported!) VHDL2008 features?
Jon
I've been slowly taking up the various enhancements provided in VHDL2008, and I find some very useful for testbench construction, particularly generic packages.
However, am I missing something, or is there still no elegant way to create a pin-wiggling BFM driven by a transaction level (procedural) interface?
Verilog has always supported this because it is possible to call a procedure from outside the module in which it is declared.
For years I've approximated this in VHDL by using an inout "transaction" record port on the BFM, with some horrible bidirectional handshaking to transfer the transactions. I then define a package of procedures which take this transaction record as an inout argument. I think other people use this approach too, but it's far from ideal as you are forced to use resolved signal types for all of the record elements.
Has anyone found a better way using (supported!) VHDL2008 features?
Jon
rickman
Dec 12, 2014, 12:44:00 AM12/12/14
to
screwdriver.
I assume you mean some sort of an interface you wish to control via
commands. I'm not sure what the problem is. I've done this many times
in VHDL. I typically have a file with commands that define the action
to take and the time to perform those actions. For example, an MCU
interface has read and write transactions with address and data to be
written on writes or verified on reads. I read a line from the file,
parsed the information, waited for the time to match the simulation time
and then passed the command to the function that handled bus transactions.
Where is the problem? Oh, this was long before VHDL2008.
--
Rick
Nikolaos Kavvadias
Dec 12, 2014, 2:15:27 AM12/12/14
to
Hi Rick and Jon,
> Please educate me on what a BFM is? I know a BFS is a type of large
> screwdriver.
@Rick: BFM stands for Bus Functional Model. It is an approach for modeling .read() and .write() transactions from/to the system bus. SystemC/TLM is a popular approach for developing BFMs and probably the right thing to do is design a SystemC/TLM BFM and cosimulate with VHDL.
A BFM generation tool would be beneficial. On a second thought, ArchC (www.archc.org) fits the bill at least partially, is open/free and has a tractable learning curve. It is an architecture description language for generating SystemC simulators (functional and cycle-accurate) of processors, but also has been extended to generating models with TLM ports (e.g. for accessing a memory via the bus), a binary utilities port, and even an LLVM compiler backend [there is a prototype for that called accgen).
So in this sense, ArchC is the closest thing to automating BFM generation since you can include TLM ports in an ArchC model and generate a SystemC simulator from it (and then you can tweak it according to your aim).
@Jon: A VHDL package for easily designing BFM models would also be of interest. I don't think such thing exists, but again you can have a look at: http://opencores.org/project,axi4_tlm_bfm
This is an AXI (AMBA 4.0) transactor and BFM by Daniel Kho of Tauhop Solutions (www.tauhop.com). It is fairly well documented and maybe you could reuse some of the code for your purpose.
Best regards
Nikolaos Kavvadias
http://www.nkavvadias.com
> Please educate me on what a BFM is? I know a BFS is a type of large
> screwdriver.
A BFM generation tool would be beneficial. On a second thought, ArchC (www.archc.org) fits the bill at least partially, is open/free and has a tractable learning curve. It is an architecture description language for generating SystemC simulators (functional and cycle-accurate) of processors, but also has been extended to generating models with TLM ports (e.g. for accessing a memory via the bus), a binary utilities port, and even an LLVM compiler backend [there is a prototype for that called accgen).
So in this sense, ArchC is the closest thing to automating BFM generation since you can include TLM ports in an ArchC model and generate a SystemC simulator from it (and then you can tweak it according to your aim).
@Jon: A VHDL package for easily designing BFM models would also be of interest. I don't think such thing exists, but again you can have a look at: http://opencores.org/project,axi4_tlm_bfm
This is an AXI (AMBA 4.0) transactor and BFM by Daniel Kho of Tauhop Solutions (www.tauhop.com). It is fairly well documented and maybe you could reuse some of the code for your purpose.
Best regards
Nikolaos Kavvadias
http://www.nkavvadias.com
rickman
Dec 12, 2014, 2:58:00 AM12/12/14
to
On 12/12/2014 2:15 AM, Nikolaos Kavvadias wrote:
> Hi Rick and Jon,
>
>> Please educate me on what a BFM is? I know a BFS is a type of large
>> screwdriver.
>
> @Rick: BFM stands for Bus Functional Model. It is an approach for modeling ..read() and .write() transactions from/to the system bus. SystemC/TLM is a popular approach for developing BFMs and probably the right thing to do is design a SystemC/TLM BFM and cosimulate with VHDL.
> Hi Rick and Jon,
>
>> Please educate me on what a BFM is? I know a BFS is a type of large
>> screwdriver.
>
>
> A BFM generation tool would be beneficial. On a second thought, ArchC (www.archc.org) fits the bill at least partially, is open/free and has a tractable learning curve. It is an architecture description language for generating SystemC simulators (functional and cycle-accurate) of processors, but also has been extended to generating models with TLM ports (e.g. for accessing a memory via the bus), a binary utilities port, and even an LLVM compiler backend [there is a prototype for that called accgen).
>
> So in this sense, ArchC is the closest thing to automating BFM generation since you can include TLM ports in an ArchC model and generate a SystemC simulator from it (and then you can tweak it according to your aim).
>
> @Jon: A VHDL package for easily designing BFM models would also be of interest. I don't think such thing exists, but again you can have a look at: http://opencores.org/project,axi4_tlm_bfm
>
> This is an AXI (AMBA 4.0) transactor and BFM by Daniel Kho of Tauhop Solutions (www.tauhop.com). It is fairly well documented and maybe you could reuse some of the code for your purpose.
That is what I did some 15 years ago. I don't get why this is a big
> A BFM generation tool would be beneficial. On a second thought, ArchC (www.archc.org) fits the bill at least partially, is open/free and has a tractable learning curve. It is an architecture description language for generating SystemC simulators (functional and cycle-accurate) of processors, but also has been extended to generating models with TLM ports (e.g. for accessing a memory via the bus), a binary utilities port, and even an LLVM compiler backend [there is a prototype for that called accgen).
>
> So in this sense, ArchC is the closest thing to automating BFM generation since you can include TLM ports in an ArchC model and generate a SystemC simulator from it (and then you can tweak it according to your aim).
>
> @Jon: A VHDL package for easily designing BFM models would also be of interest. I don't think such thing exists, but again you can have a look at: http://opencores.org/project,axi4_tlm_bfm
>
> This is an AXI (AMBA 4.0) transactor and BFM by Daniel Kho of Tauhop Solutions (www.tauhop.com). It is fairly well documented and maybe you could reuse some of the code for your purpose.
deal. It seems like a pretty straight forward thing to me. The only
work involved was writing the code to parse the text file to drive the
bus. Am I missing something?
--
Rick
Jim Lewis
Dec 13, 2014, 11:11:10 AM12/13/14
to
Hi Jon,
Still using records myself, however, ...
VHDL 2008 introduces generic packages. Allows generic packages to be passed on entity interfaces. Allows generic instances within an architecture. Has always allowed signals to be defined in packages. This would solve the BFM connection, however, when calling the transaction subprogram, the subprogram still needs to pass the signals it needs to drive - for the time being, I plan on using a record reference for that.
When vendors support these features, it will offer us a feature similar to SystemVerilog interfaces (without the concurrent region of the interface and modports (which allow constraint checking on who is allowed to drive which signals and who is allowed to call which subprograms)).
I have prototypes and such. I have submitted bug reports. I need others to indicate they would like such features supported.
Best Regards,
Jim
Still using records myself, however, ...
VHDL 2008 introduces generic packages. Allows generic packages to be passed on entity interfaces. Allows generic instances within an architecture. Has always allowed signals to be defined in packages. This would solve the BFM connection, however, when calling the transaction subprogram, the subprogram still needs to pass the signals it needs to drive - for the time being, I plan on using a record reference for that.
When vendors support these features, it will offer us a feature similar to SystemVerilog interfaces (without the concurrent region of the interface and modports (which allow constraint checking on who is allowed to drive which signals and who is allowed to call which subprograms)).
I have prototypes and such. I have submitted bug reports. I need others to indicate they would like such features supported.
Best Regards,
Jim
Brian Drummond
Dec 14, 2014, 7:58:58 AM12/14/14
to
to Tristan. He seems to be on a roll these days.
ghdl (not 0.31 but 0.32 which is in the pre-release stage, anyone can
build it from source) supports enough VHDL-2008 to run OSVVM 2014.01 now.
If you have a prototype or testcase requiring additional VHDL-2008
support beyond that, it would be great to get that into the next release.
- Brian
Andy
Dec 15, 2014, 12:13:21 AM12/15/14
to
Records work pretty well when you understand what the initializer does on a signal or port declaration. It can be used to keep the signal benign until/unless someone drives it.
Another approach I have used is to declare a package procedure(s) with separate in/out/inout signal ports, that provides your procedural interface(s) to the BFM.
Then in the process where you want to call the package procedure(s), you can overload the package procedure(s) so that only pertinent, per-call info is passed to the local procedure(s). A procedure declared in a process can access/drive signals visible to the process without them having to be explicitly passed to the local procedure. Just have the body of the local procedure call the package procedure with the full interface.
Andy
Another approach I have used is to declare a package procedure(s) with separate in/out/inout signal ports, that provides your procedural interface(s) to the BFM.
Then in the process where you want to call the package procedure(s), you can overload the package procedure(s) so that only pertinent, per-call info is passed to the local procedure(s). A procedure declared in a process can access/drive signals visible to the process without them having to be explicitly passed to the local procedure. Just have the body of the local procedure call the package procedure with the full interface.
Andy
Daniel Kho
Dec 18, 2014, 3:34:58 PM12/18/14
to
The project even uses OS-VVM to do coverage-driven constrained randomisation of test vectors.
Cheers, dan
0 new messages