![]() |
|
|
|
#1 |
|
I'm a new and clumsy VHDL user but wish to generate a data file
outside VHDL and then read it as stimulus to my circuit under test in a testbench. The problem is that I need to serialize the data and feed it to my single-bit data input. Could someone point me to a useable example of this sort of thing? What's critical is that I be able to assign the values read byte-by-byte from the file, preferably in binary, to a data type, e.g. std_logic-vector, such that I can easily serialize it in VHDL. Any pointers? Please CC me in email as you reply, but reply to the group. thanks, Richard Erlacher Richard Erlacher |
|
|
|
|
#2 |
|
Posts: n/a
|
Richard Erlacher wrote:
> I'm a new and clumsy VHDL user but wish to generate a data file > outside VHDL and then read it as stimulus to my circuit under test in > a testbench. > > The problem is that I need to serialize the data and feed it to my > single-bit data input. > > Could someone point me to a useable example of this sort of thing? > What's critical is that I be able to assign the values read > byte-by-byte from the file, preferably in binary, to a data type, e.g. > std_logic-vector, such that I can easily serialize it in VHDL. > > Any pointers? I like to declare serial data packets as vector constants like this. constant my_packet : unsigned := x"041108004500005800010000fe11de9f" & x"81c49a86b0a81101400000a100440000" & x"3082003802010004067075626c6963a0" & x"2b02014802010002010030203082000c" & x"06082b0601020101020005003082000c" & x"06082b0601020101050005005a00"; Then all you have to do is make a bit_counter in a synchronous process and output my_packet(bit_counter) every cycle. Use a script or editor macro to convert the data file to text vhdl constants. -- Mike Treseler Mike Treseler |
|
|
|
#3 |
|
Posts: n/a
|
Richard Erlacher wrote:
> Thanks for such a timely response! > > I've considered making each packet a constant array, but I have to test > a packet processor with many, Many, packets captured from a network, in > order to verify, among other things, my CRC checking. These packets are > in binary format when captured, and include the CRC. Since I have to > check my circuitry against what's used on the network, I'd like to use > the "real McCoy" rather than computing the CRC separately and appending > it, and then editing the resulting file into the testbench. Why not capture all the data including CRC and post process into constants using a script? It's post processed in any case and hex data is no less real than binary. > What I want to do is put about 20 or 30 packets in a file and read them, > ultimately more of them, extracting the packet length from the header, > and subsequently testing the CRC at the appropriate time in the > bitstream, just to verify I've done my work correctly, and to give it a > thorough workout. > What data type should I assign to my transient input variable? Should I > make it an array and load it at the beginning of the process, or should > I read it byte by byte? Since full packets of data are available in advance, I would do a pseudo-serial fcs verification on the full packet using a for loop. function fcs_ok (arg : std_logic_vector) return boolean -- Mike Treseler Mike Treseler |
|
|
|
#4 |
|
Posts: n/a
|
Unfortunately, I haven't got a tool for snagging the entire packet
inclusive of its CRC from the network, so I have to do things the way I am doing it. However, the current challenge is setting up and using the file contents to verify my CRC logic. (Keep in mind I'm a neophyte with this VHDL stuff and only get to it in my spare time.) I've gotten the impression that it's possible to assign a constant array of type bit-vector and simply address each bit with a count. Is that true? If I did that, I suppose I'd be able to process the entire stream of bits from a single block of text that I could incorporate in my testbench and not fool with a file at all. Then if I wanted to use several packets, I'd simply assign them as separate constants and use them one at a time in that manner. Does that make any sense? How would I specify that, using, say, the text block you included in your first message? thanks, Richard Erlacher Mike Treseler <> wrote in message news:<>... > Richard Erlacher wrote: > > > Thanks for such a timely response! > > > > I've considered making each packet a constant array, but I have to test > > a packet processor with many, Many, packets captured from a network, in > > order to verify, among other things, my CRC checking. These packets are > > in binary format when captured, and include the CRC. Since I have to > > check my circuitry against what's used on the network, I'd like to use > > the "real McCoy" rather than computing the CRC separately and appending > > it, and then editing the resulting file into the testbench. > > Why not capture all the data including CRC and post process > into constants using a script? It's post processed in any > case and hex data is no less real than binary. > > > What I want to do is put about 20 or 30 packets in a file and read them, > > ultimately more of them, extracting the packet length from the header, > > and subsequently testing the CRC at the appropriate time in the > > bitstream, just to verify I've done my work correctly, and to give it a > > thorough workout. > > > What data type should I assign to my transient input variable? Should I > > make it an array and load it at the beginning of the process, or should > > I read it byte by byte? > > Since full packets of data are available in advance, > I would do a pseudo-serial fcs verification on the full packet > using a for loop. > > function fcs_ok (arg : std_logic_vector) > return boolean > > -- Mike Treseler Richard Erlacher |
|
|
|
#5 |
|
Posts: n/a
|
Richard Erlacher wrote:
> Unfortunately, I haven't got a tool for snagging the entire packet > inclusive of its CRC from the network, so I have to do things the way > I am doing it. So you have some sample packet data, but no known good fcs? In that case, the testbench will have to calculate the fcs and append it. You will need some other way to verify that you got it right. Do you know the bit order and byte order of the samples? Are you using hdlc flags between the packets? If so, are your samples unstuffed? > However, the current challenge is setting up and using the file > contents to verify my CRC logic. (Keep in mind I'm a neophyte with > this VHDL stuff and only get to it in my spare time.) I've gotten the > impression that it's possible to assign a constant array of type > bit-vector and simply address each bit with a count. Is that true? Yes, you can access any vhdl vector type with a natural index. The order you need to access is affected by bit order and byte order of the constant vector and your crc spec. > If I did that, I suppose I'd be able to process the entire stream of > bits from a single block of text that I could incorporate in my > testbench and not fool with a file at all. Yes. I expect that that will save you a lot of time. > Then if I wanted to use > several packets, I'd simply assign them as separate constants and use > them one at a time in that manner. Does that make any sense? Yes. That's it. You can even make a table if you want to get fancy: http://groups.google.com/groups?q=how_many_frames > How would I specify that, using, say, the text block you included in your > first message? That "text block" is a VHDL vector declaration representing a complete packet. Normally you would put these in a package or between IS and BEGIN at the top of the architecture. -- Mike Treseler Mike Treseler |
|
![]() |
| Thread Tools | Search this Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Error: Physical sythesis tool PALAC is not supported by Formal Verification tool Conf | bbiandov | Software | 0 | 12-22-2008 05:25 AM |
| SONY DVD RW DW-G120A SOMETIMES FAILS...... | atlantic965 | DVD Video | 0 | 06-18-2006 10:36 PM |
| problems backing up dvds | Lawrence Traub | DVD Video | 11 | 09-27-2005 07:34 PM |
| Burn process failed - help! Log file posted for help troubleshooting | Michael Mason | DVD Video | 1 | 08-16-2004 09:24 PM |
| Pioneer A05 Problems | Bill Stock | DVD Video | 8 | 11-28-2003 05:03 AM |