need a cheap student edition FPGA

[pini]

reg [7:0] TYPEFIL_REG=uno;
You can initialize when targeting to synthesis (only for
verification). Use reset instead.
if(posedge clock or negedge reset_n) begin
if(~reset_n) ....
else ..

Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061216.7206d4cf@posting.google.com>...

filippdavid@yahoo.com (filippo) wrote in message news:<18add487.0402060204.340e7b39@posting.google.com>...
I' m having great troubles making a small project on FPGA in Verilog.
I have to do it for an exam at university, it shoul be simple but it's
becoming hell.

problem:

all simulations with modelsim are good, but it just doesn' t work on
the real FPGA and i don't know where to find a solution (or where is
the real problem).

Did you perform both pre- and post-route simulations? What does your
test bench actually do? Is it a real bus-functional model of your
microcontroller? Or are you just setting and clearing signals in some
arbitrary fashion? I would imagine that this is the root of your
problem -- your simulation is bogus. As they say: garbage in, garbage
out?

What about your timing constraints?

of the 10+ modules one seems to be the most troublesome, our
IO_control, here is the code ,please help.

---------------------------------------------------------------------------------
module IO_control(ALE,NWR,NRD,DIR,DA,MIN,MAX,SEL,TYPEFIL,AMPLIF,DIVFRQ,clk);
input ALE;
input NWR;
input clk;
input NRD;
input DIR;
input [7:0] MIN;
input [7:0] MAX;
inout [7:0] DA;
output [7:0] SEL;
output [7:0] TYPEFIL;
output [7:0] AMPLIF;
output [7:0] DIVFRQ;

parameter uno = 8'b0000_0001;

reg [7:0] ADDR_REG;
reg [7:0] DO_REG;
reg [7:0] SEL_REG=uno;
reg [7:0] TYPEFIL_REG=uno;
reg [7:0] AMPLIF_REG=uno;
reg [7:0] DIVFRQ_REG=uno;
^^^^^^^^^^^
This initialization is illegal, or at least ignored by a synthesis
tool.
Use an external reset to actually initialize these registers.

assign SEL = SEL_REG;
assign TYPEFIL = TYPEFIL_REG;
assign AMPLIF = AMPLIF_REG;
assign DIVFRQ = DIVFRQ_REG;

Ummmmm...why not declare the SEL, TYPEFIL, AMPLIF and DIVFRQ outputs
as regs and not bother with this silly assign? Also: explicitly
declare whether your module outputs are wires or regs. It's a good
style habit.

assign DA = (DIR) ? 8'bzzzz_zzzz : DO_REG;

always @ (posedge clk)
begin
if (ALE) ADDR_REG <= DA;

if (~NWR)
case (ADDR_REG)
8'b0000_0001 : SEL_REG <= DA;
8'b0000_0010 : TYPEFIL_REG <= DA;
8'b0000_0100 : AMPLIF_REG <= DA;
8'b0000_1000 : DIVFRQ_REG <=DA;
default DO_REG <= 8'b1111_1111;
endcase

if (~NRD)
case (ADDR_REG)
8'b0000_0001 : DO_REG <= SEL_REG;
8'b0000_0010 : DO_REG <= TYPEFIL_REG;
8'b0000_0100 : DO_REG <= AMPLIF_REG;
8'b0000_1000 : DO_REG <= DIVFRQ_REG;
8'b0001_0000 : DO_REG <= MIN;
8'b0010_0000 : DO_REG <= MAX;
default DO_REG <= 8'b1111_1111;
endcase
end

Umm, another style issue. Use more than one always statement for the
above. You have three separate registers; put 'em in their own always
blocks.

Also: are ALE, NRD, NWR, DA all synchronous to your clock?

Remember that ALE is a latch enable -- are you sure that your address
is actually valid when the latch enable is active and goes away?

--a

 

[filippo]

I made a lot of changes (like the reset) , i'll post the new source soon!

 

[filippo]

Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061216.7206d4cf@posting.google.com>...

Did you perform both pre- and post-route simulations? What does your
test bench actually do? Is it a real bus-functional model of your
microcontroller? Or are you just setting and clearing signals in some
arbitrary fashion? I would imagine that this is the root of your
problem -- your simulation is bogus. As they say: garbage in, garbage
out?

What about your timing constraints?

both simulations were succesful

This initialization is illegal, or at least ignored by a synthesis
tool.
Use an external reset to actually initialize these registers.

this has changed

assign SEL = SEL_REG;
assign TYPEFIL = TYPEFIL_REG;
assign AMPLIF = AMPLIF_REG;
assign DIVFRQ = DIVFRQ_REG;

Ummmmm...why not declare the SEL, TYPEFIL, AMPLIF and DIVFRQ outputs
as regs and not bother with this silly assign? Also: explicitly
declare whether your module outputs are wires or regs. It's a good
style habit.

humm , i'll think about this

assign DA = (DIR) ? 8'bzzzz_zzzz : DO_REG;

always @ (posedge clk)
begin
if (ALE) ADDR_REG <= DA;

if (~NWR)
case (ADDR_REG)
8'b0000_0001 : SEL_REG <= DA;
8'b0000_0010 : TYPEFIL_REG <= DA;
8'b0000_0100 : AMPLIF_REG <= DA;
8'b0000_1000 : DIVFRQ_REG <=DA;
default DO_REG <= 8'b1111_1111;
endcase

if (~NRD)
case (ADDR_REG)
8'b0000_0001 : DO_REG <= SEL_REG;
8'b0000_0010 : DO_REG <= TYPEFIL_REG;
8'b0000_0100 : DO_REG <= AMPLIF_REG;
8'b0000_1000 : DO_REG <= DIVFRQ_REG;
8'b0001_0000 : DO_REG <= MIN;
8'b0010_0000 : DO_REG <= MAX;
default DO_REG <= 8'b1111_1111;
endcase
end

Umm, another style issue. Use more than one always statement for the
above. You have three separate registers; put 'em in their own always
blocks.

Also: are ALE, NRD, NWR, DA all synchronous to your clock?

Remember that ALE is a latch enable -- are you sure that your address
is actually valid when the latch enable is active and goes away?

 

[Andy Peters]

bknpk@hotmail.com (pini) wrote in message news:<ca9059d7.0402062200.501f626f@posting.google.com>...

TYPEFIL_REG=uno;
You can initialize when targeting to synthesis (only for
verification). Use reset instead.

My point was that if you don't have a reset, the initialize will fool you.

-a

 

[Tom Hawkins]

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405121132.2e45e653@posting.google.com>...

With two clocks and two write ports!?

Ok, maybe not that particular case, but most other configurations of
dual-port RAM can be infered. In Verilog at least, isn't this a
problem with the language rather than the FPGA tools (i.e. you can't
write to the same variable from two different processes)?

Verilog does not have this restriction. I've searched the LRM and
I've run testcases through two reputable implementations without
complaints (ncverilog, icarus).

Hence my frustration. We can precisely describe a dual port block-ram
in Verilog, yet the tools draw a blank. We can even preset RAMs with
values, but most, if not all, completely disregard initial statements.

Given the size of their development staff and the prices they are able
to charge, how can they still ignore important parts of the language
standard?

-Tom

Open-source doesn't *have* to mean no-cost...

Sure. I was more refering to that fact that due to the quality & size
of some open source/free software projects, the bar has been raised
significantly.

Cheers,
JonB

 

[Martin Thompson]

tom1@launchbird.com (Tom Hawkins) writes:

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405121132.2e45e653@posting.google.com>...
With two clocks and two write ports!?

Ok, maybe not that particular case, but most other configurations of
dual-port RAM can be infered. In Verilog at least, isn't this a
problem with the language rather than the FPGA tools (i.e. you can't
write to the same variable from two different processes)?

Verilog does not have this restriction. I've searched the LRM and
I've run testcases through two reputable implementations without
complaints (ncverilog, icarus).

Hence my frustration. We can precisely describe a dual port block-ram
in Verilog, yet the tools draw a blank. We can even preset RAMs with
values, but most, if not all, completely disregard initial statements.

I've asked Synplify, and they can infer two-read, one-write, two-clock
RAMs currently. They plan to support the full two port functionality
in future...

Initials are another thing though!

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

 

[Jon Beniston]

Ok, maybe not that particular case, but most other configurations of
dual-port RAM can be infered. In Verilog at least, isn't this a
problem with the language rather than the FPGA tools (i.e. you can't
write to the same variable from two different processes)?

Verilog does not have this restriction. I've searched the LRM and
I've run testcases through two reputable implementations without
complaints (ncverilog, icarus).

You are correct. Although it is only ever supported for simulation. I
can kind of understand why though. Take the following:

module test(c1, c2, a, b, d);
input c1, c2, a, b;
output d;
reg d;
always @(posedge c1)
d <= a;
always @(posedge c2)
d <= b;
endmodule

What logic would you synthesize it to? Have you tried this with a
behavioural synthesis tool? Maybe that could do a better job.

Hence my frustration. We can precisely describe a dual port block-ram
in Verilog, yet the tools draw a blank. We can even preset RAMs with
values, but most, if not all, completely disregard initial statements.

Isn't this fixed in v200x? I do agree it's all a bit crap.

Cheers,
JonB

 

[john jakson]

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405140056.23ca67ac@posting.google.com>...

Ok, maybe not that particular case, but most other configurations of
dual-port RAM can be infered. In Verilog at least, isn't this a
problem with the language rather than the FPGA tools (i.e. you can't
write to the same variable from two different processes)?

Verilog does not have this restriction. I've searched the LRM and
I've run testcases through two reputable implementations without
complaints (ncverilog, icarus).

You are correct. Although it is only ever supported for simulation. I
can kind of understand why though. Take the following:

module test(c1, c2, a, b, d);
input c1, c2, a, b;
output d;
reg d;
always @(posedge c1)
d <= a;
always @(posedge c2)
d <= b;
endmodule

What logic would you synthesize it to? Have you tried this with a
behavioural synthesis tool? Maybe that could do a better job.

Hence my frustration. We can precisely describe a dual port block-ram
in Verilog, yet the tools draw a blank. We can even preset RAMs with
values, but most, if not all, completely disregard initial statements.

Isn't this fixed in v200x? I do agree it's all a bit crap.

Cheers,
JonB

BRams are a very special case since most of the time the 2 address are
different so the 2 clock domains are fully independant. If the address
should be the same then the result of the 2 concurrent writes is
undefined but the user should have taken care about that. given that,
the synthesis should be able to handle it with a warning for same
addresses.

regards

johnjakson_usa_com

 

[Jon Beniston]

johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0405141717.7eea7369@posting.google.com>...

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405140056.23ca67ac@posting.google.com>...
Ok, maybe not that particular case, but most other configurations of
dual-port RAM can be infered. In Verilog at least, isn't this a
problem with the language rather than the FPGA tools (i.e. you can't
write to the same variable from two different processes)?

Verilog does not have this restriction. I've searched the LRM and
I've run testcases through two reputable implementations without
complaints (ncverilog, icarus).

You are correct. Although it is only ever supported for simulation. I
can kind of understand why though. Take the following:

module test(c1, c2, a, b, d);
input c1, c2, a, b;
output d;
reg d;
always @(posedge c1)
d <= a;
always @(posedge c2)
d <= b;
endmodule

What logic would you synthesize it to? Have you tried this with a
behavioural synthesis tool? Maybe that could do a better job.

Hence my frustration. We can precisely describe a dual port block-ram
in Verilog, yet the tools draw a blank. We can even preset RAMs with
values, but most, if not all, completely disregard initial statements.

Isn't this fixed in v200x? I do agree it's all a bit crap.

Cheers,
JonB

BRams are a very special case since most of the time the 2 address are
different so the 2 clock domains are fully independant. If the address
should be the same then the result of the 2 concurrent writes is
undefined but the user should have taken care about that. given that,
the synthesis should be able to handle it with a warning for same
addresses.

Sure, but it seemed like the OP was suggesting that synthesis tools
should support everything possible in the language.

Cheers,
JonB

 

[Jim Lewis]

Jon Beniston wrote:

Ok, maybe not that particular case, but most other configurations of
dual-port RAM can be infered. In Verilog at least, isn't this a
problem with the language rather than the FPGA tools (i.e. you can't
write to the same variable from two different processes)?

Verilog does not have this restriction. I've searched the LRM and
I've run testcases through two reputable implementations without
complaints (ncverilog, icarus).


You are correct. Although it is only ever supported for simulation. I
can kind of understand why though. Take the following:

module test(c1, c2, a, b, d);
input c1, c2, a, b;
output d;
reg d;
always @(posedge c1)
d <= a;
always @(posedge c2)
d <= b;
endmodule

What logic would you synthesize it to? Have you tried this with a
behavioural synthesis tool? Maybe that could do a better job.

Another interesting question about the proposed
code above is, during a given simulation cycle
if both clocks rise at the same time, which
executes first in simulation?

Can you re-write the code so that one always
has wins or if both happen a the same time
an 'X' is generated on d?


Cheers,
Jim

 

[rickman]

Jim Lewis wrote:

Jon Beniston wrote:

Ok, maybe not that particular case, but most other configurations of
dual-port RAM can be infered. In Verilog at least, isn't this a
problem with the language rather than the FPGA tools (i.e. you can't
write to the same variable from two different processes)?

Verilog does not have this restriction. I've searched the LRM and
I've run testcases through two reputable implementations without
complaints (ncverilog, icarus).


You are correct. Although it is only ever supported for simulation. I
can kind of understand why though. Take the following:

module test(c1, c2, a, b, d);
input c1, c2, a, b;
output d;
reg d;
always @(posedge c1)
d <= a;
always @(posedge c2)
d <= b;
endmodule

What logic would you synthesize it to? Have you tried this with a
behavioural synthesis tool? Maybe that could do a better job.


Another interesting question about the proposed
code above is, during a given simulation cycle
if both clocks rise at the same time, which
executes first in simulation?

Can you re-write the code so that one always
has wins or if both happen a the same time
an 'X' is generated on d?

Same as in the real world, the result is indeterminate.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[JingleBEV]

I have a brand new book for sale:
Rapid Prototyping of Digital Systems, by James O. Hamblen and Michael D.
Furman, 2nd Edition
ISBN: 0-7923-7439-8

Include Altera's 10.22 student-edition software.

$90.00 CND (include shipping anywhere in Canada)

If interested, send me an email n_quan@NOSPAMyahoo.com
remove the capital letters before sending.

thanks.

 

[Pablo Bleyer Kocik]

What do you mean when you say it doesn't support begin/end blocks?

I am the maintainer of UltraEdit's Verilog-2001 mode. It should not
only recognize begin/end blocks but also case/endcase, fork/join,
specify/endspecify, table/endtable and config/endconfig as indentation
strings...

Regards.

 

[Kholdoun TORKI]

Try this link. A great software utility running on Windows.

http://www.logiccell.com/~jean/LFSR/

Regards,
=================
Kholdoun TORKI
http://cmp.imag.fr
==================

Dev wrote:

Hi all,


Could you pls explain what LSFR is ?
or where can I obtain some information on them.

thanks in advance

Dev

 

[glen herrmannsfeldt]

rickman wrote:

Actually, what you are describing is a VHDL coding issue, not a MAP
issue. If you want a 21 bit result from a VHDL add (I don't know
Verilog well enough to say) you have to have at least one 21 bit input.
VHDL won't assume that you expect a 21 bit result.

I am not sure about verilog. If I assign to a variable
the same width as the operands of +, I get warnings
about truncated bits.

One book says that {cout, sum} = in1 + in2 + cin;
will generate a full adder.

Another book says that the width for + is maximum of the width
of the two operands.

cross posted to comp.lang.verilog, to see if anyone there can say.

-- glen

 

[Shalom Bresticker]

In verilog,

{cout, sum} = in1 + in2 + cin;

will perform an addition of width max({cout, sum}, in1, in2, cin).

The statement that "the width for + is maximum of the width
of the two operands" is true if "a+b" is in isolation ('self-determined'
in Verilog terms).

However, for c = a+b, then the operands are extended to width
max(a,b,c), and only then is the addition performed.

Shalom


glen herrmannsfeldt wrote:

rickman wrote:

Actually, what you are describing is a VHDL coding issue, not a MAP
issue. If you want a 21 bit result from a VHDL add (I don't know
Verilog well enough to say) you have to have at least one 21 bit input.
VHDL won't assume that you expect a 21 bit result.

I am not sure about verilog. If I assign to a variable
the same width as the operands of +, I get warnings
about truncated bits.

One book says that {cout, sum} = in1 + in2 + cin;
will generate a full adder.

Another book says that the width for + is maximum of the width
of the two operands.

cross posted to comp.lang.verilog, to see if anyone there can say.

-- glen

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary

 

[don]

turbo18t wrote:

I need a small FPGA to use in a lab at school. It doesn't have to be
fast, have millions of gates or in any way be a high performance
model. It just has to work. In the class we're designing relatively
small ALU's and I want to do it in Verilog and burn it. It has to be
a protoboard with I/O's and a PC interface. My friend suggested the
Xilinx Spartan series. Any help is appreciated. Thanks.

Your friend is probably talking about Xilinx's "Spartan 3 Starter Kit."
Xilinx's online store (www.xilinx.com) sells the complete kit for $99
USD. This is a XC3S200 FPGA mounted on a small board, complete with a
PS/2, VGA, and RS/232 connectors. It even has 1MB of memory (SRAM!)

This is an *excellent* starter board. You get more than enough
programmable gates to do a reasonable school project, and its the lowest
priced *modern* FPGA board you can find. There are 2 things I don't
like about the board... the 'I/O connectors' are female, meaning it's
not convenient to probe signals (on an oscilloscope.) The other
annoyance is the SRAM isn't directly accessible from the JTAG interface.
I.e., there's no easy way to initialize (write) the SRAM.

Xilinx seems to be 'out-of-stock' at the moment, but you could check
www.digilentinc.com (Digilent manufactures these boards for Xilinx.)

Also consider Xess's XSA/50 and XSA/100 boards. They don't give you
as much programmable logic, but the board has more memory (4MB SDRAM),
and a full featured 'daughtercard' (+$100 USD) with stereo audio
in/out, and a large 'prototype' area (breadboard) for wiring your
own circuits. Since you said you're doing a small ALU, and you want
I/Os, the Xess board might be a better choice for you. Xess's
website also has a good # of 'sample designs' (by Xess and
third-parties.) This can really help a novice get started with
some topics (like how to generate a VGA-signal to display on your
monitor!)

 

[Rich Webb]

On Sun, 3 Oct 2004 11:49:23 +0200, "Ulf Samuelsson" <ulf@atmel.dot.com>
wrote:

"turbo18t" <mkracer3@yahoo.com> skrev i meddelandet
news:35824643.0409281311.5d0fa28a@posting.google.com...
I need a small FPGA to use in a lab at school. It doesn't have to be
fast, have millions of gates or in any way be a high performance
model. It just has to work. In the class we're designing relatively
small ALU's and I want to do it in Verilog and burn it. It has to be
a protoboard with I/O's and a PC interface. My friend suggested the
Xilinx Spartan series. Any help is appreciated. Thanks.



The STK500 + STK594 FPSLIC will give you a cool tool since it also contains
an onchip AVR
The toolset will allow you to test the FPGA using the AVR.
It is much nicer to write testvectors in C, than in VHDL.
Also the display of simulation results is much nicer using AVR studio, than
the average waveform window.

Is there any chance that Atmel will release a free or low-cost version
of its HDL development tools for the FPSLICs or even the ATF1500 chips?
Given that Xilinx and Altera have HDL toolchains that are register-ware,
Atmel is competing in a tough market.

--
Rich Webb Norfolk, VA

 

[sirisha]

Prasanth Kumar <lunix@comcast.net> wrote in message news:<1099375654.3608.3.camel@localhost.localdomain>...

On Mon, 2004-11-01 at 19:54 -0800, sirisha wrote:
Arithmetic operations are among the most basic instructions in
microprocessors and many other ASICs. From SPECfp2000 benchmark, about
15% of the floating-point ALU operations are additions and about 10%
are subtractions. The most time consuming arithmetic operation is the
floating-point division, then comes to the multiplication and then the
addition/subtraction. The speed of those arithmetic operations
directly links to the overall performance of the ALU units and so the
computers. Since floating-point addition/subtraction units are built
on top of integer addition/subtraction units, performance of integer
addition/subtraction units have direct link to performance of
floating-point units.

In this class project, we design 2 32-bit addition/subtraction units,
one uses straight simple ripple-carry algorithm and the other uses
carry-looked-ahead algorithm. Our study will basically explore the
correlations between areas, speeds, algorithms and will at least cover
the information as listed below. All analyses will be performed based
on both theory and measurements and explanation will be provided for
discrepancies between the twos.
ƒ 1)Correlation of areas and speeds for both algorithms will be
determined
2)The two designs will be optimized for areas and analysis on speeds
will be performed
3)The two designs will be optimized for speeds and analysis on areas
will be performed
4)Costs and speeds of a 32-bit floating-point unit if the unit is
built based on one addition/subtraction algorithm versus the other
will be relatively evaluated

This project start with verilog code. I am unable to start the
code.I need help from group.

Thanks
sirisha.

Here is some help to start the code:

module ripple(sum, opa, opb);

// you fill in the code here

endmodule

can u give some more ideas of this project.difference between ripple
and carry look ahead adders.

thanks
sirisha.

 

[Jim Wu]

You're welcome.

I didn't try this myself, but theoretically it should work: if you need
"seq" to be more than 1 digit, you can try swrite* tasks.

Jim

"Eric Crabill" <eric.crabill@xilinx.com> wrote in message
news:419CE33E.503B4253@xilinx.com...

Thanks, I am going to try integrating this into my
existing TIFF file writer and I'll let you know
how it works out for me. I really appreciate the
thought you put into it.

Eric

Jim Wu wrote:

A typo, fn should have been defined as "reg [10*8:1] fn;".

"Jim Wu" <nospam@nospam.com> wrote in message
news:cngs9m$jq2@cliff.xsj.xilinx.com...
Try this (tested in mti 5.8e):

module wr_bin ();

reg [7:0] data;
reg [10*8:0] fn;
reg [7:0] seq;

integer fd;
integer i, j;

initial begin

for (j = 0; j < 8; j = j + 1) begin
seq = 8'h30 + j;
fn = {"frame", seq, ".tif"};
fd = $fopen(fn, "wb");
for (i = 0; i < 256; i = i + 1) begin
data = i;

if (data == 0) begin
$fwriteb(fd, "%u", data);
$fseek(fd, 1, 0);
end
else
$fwriteb(fd, "%c", data);
end


$fclose(fd);
end

$display("Done");
$finish;
end

HTH,
Jim
jimwu88NOOOSPAM@yahoo.com (remove capital letters)
http://www.geocities.com/jimwu88/chips

"Eric Crabill" <eric.crabill@xilinx.com> wrote in message
news:419BDA61.4AF0BC09@xilinx.com...

Dude, you rock!!! Since I'm using Modelsim at home
for my hobby projects, this will work fantastic...
Now I can write out TIFF files direct from Verilog.

Let me ask another question, if you don't mind. Do
you (or anyone reading) know if it's possible to
open files with dynamic file names? By that, I
mean instead of using the string "test.bin" in $fopen
is there a way to form a string with a 2D reg and
then pass that as the file name? I tried playing
around with this, but the simulator I was using at
the time did not like anything but actual strings...

My desire is to have a loop, that writes each display
frame to a separate file, with names like:

frame01.tif
frame02.tif
frame03.tif
frame04.tif
and so on...

Thanks, I appreciate your help,
Eric

Jim Wu wrote:

Hi,

Well, let me know if you figure this one out. I had
a similar issue -- I wanted a Verilog simulation to
write out a TIFF file. I couldn't find a way to write
out a binary file, so wrote out ASCII data values to
text file and then post-processed it into a binary
TIFF file using a small program I wrote in C.

The attached code is kind of kludge, but it works, with modelsim
5.8e
anyway.

HTH,
Jim
jimwu88NOOOSPAM@yahoo.com (remove capital letters)
http://www.geocities.com/jimwu88/chips

module wr_bin ();

reg [7:0] data;

integer fd;
integer i;

initial begin
fd = $fopen("test.bin", "wb");

for (i = 0; i < 256; i = i + 1) begin
data = i;

if (data == 0) begin
$fwriteb(fd, "%u", data);
$fseek(fd, 1, 0);
end
else
$fwriteb(fd, "%c", data);
end

$fclose(fd);
$display("Done");
$finish;
end

endmodule