Followup to:  <bpc2nt$1m9fjq$1@ID-132015.news.uni-berlin.de>
By author:    "Josh Pfrimmer" <yeah_spam_me@thisaddress.com>
In newsgroup: comp.arch.fpga
> 
> I'd prefer a solution that only requires students to edit one file to
> change the program for both the hardware implementation (I've noticed that
> CoreGen puts the correct data in the EDIF file) AND the simulation.  It's a
> pretty challenging lab as it is, without the extra pitfall of having
> mismatching simulation/hardware programs.
> 

I usually find these kinds of situations are excellent excuses to
write a couple of Perl scripts.

Oh yes, am I the only one who thinks it's somewhat bizarre that almost
none of these tools can deal with a plain old binary file?

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Robert Baumgartner wrote:

> In xilinx coregen generate a .coe file with the memory editor (found in the
> tool menu) with the correct depth
> an width for the memory you want. This will give you a .coe and a .mif file.
> Then generate your memory with
> coregen. Go to the last page of the configuration (for a dual port block
> memory for virtex pro it is page 4);
> there you select "load init file" ,  push on the button "load file" and fill
> in the name of the .coe file you
> generated before. Look in the generated VHDL file, the name of the .mif file
> in the VHDL file should match
> the file generated by the memory editor. For the Simulation put a .mif file
> with the correct content in your
> simulation directory. Your Simulator should read the .mif file via textio.

Or use an array of constants for
ease of simulation, and let
synthesis handle the rom details.

       -- Mike Treseler

Josh Pfrimmer wrote:

> Hi experts,
>
> I've looked through the archives, and the Xilinx literature, and haven't
> found an answer to this question, so please forgive me if it's obvious
> and/or everyone's sick of answering.  I've spent a couple of days on this.
>
> I'm upgrading a lab here at UVic from an xc4000 based board to a Spartan2.
> So as not to complicate the upgrade needlessly, we'd like to stick with
> Foundation 4.2i tools and design flow.  (We'll upgrade that next semester..
> one thing at a time.) The students are to create a pipelined 8-bit
> processor in either VHDL or Schematic.  They use the Foundation simulator
> to debug.
>
> The first issue I came up against was that they now have to use CoreGen to
> make memories (program, data, stack), where we used to use LogicBlox.
> Specifying memory contents in LogicBlox used a .mem file.  In Coregen, you
> have to use a .coe file.  Easy enough, and when I go all the way through
> implementation, I have no problems at all.
>
> When I want to do a functional simulation, however, the program memory is
> all zeroes.  How best to go about getting the .coe data into the Foundation
> functional simulator?  The VHDL and verilog files reference a .mif file.
> The simulator allows one to "load contents" via a hex file.
>
> I'd prefer a solution that only requires students to edit one file to
> change the program for both the hardware implementation (I've noticed that
> CoreGen puts the correct data in the EDIF file) AND the simulation.  It's a
> pretty challenging lab as it is, without the extra pitfall of having
> mismatching simulation/hardware programs.
>
> Thanks for your time,
>
> JP
>
> --
>                 Josh Pfrimmer, B.Eng.
> _________________________________________
>  University of Victoria, ECE
>  jpfrimmer<AT>ece<DOT>uvic<DOT>ca
> _________________________________________
> ->My views and opinions are not necessarily UVic's

Hi,

In xilinx coregen generate a .coe file with the memory editor (found in the
tool menu) with the correct depth
an width for the memory you want. This will give you a .coe and a .mif file.
Then generate your memory with
coregen. Go to the last page of the configuration (for a dual port block
memory for virtex pro it is page 4);
there you select "load init file" ,  push on the button "load file" and fill
in the name of the .coe file you
generated before. Look in the generated VHDL file, the name of the .mif file
in the VHDL file should match
the file generated by the memory editor. For the Simulation put a .mif file
with the correct content in your
simulation directory. Your Simulator should read the .mif file via textio.


Robert

>Sure, but the functional simulator in Foundation doesn't read the coe, mif,
>or edf file.  I'm hoping to find the best possible way to allow the
>students to change their program and have those changes show up in both
>simulation and hardware.

Maybe this would be a good introduction to tools-in-real-life?

Can you kludge together something to push the info in those files
into some place/form where the simulator will see it?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

"Tero Rissa" <no_spam_for_me@thanks.invalid> wrote in message
news:bpi8c4$6ls$1@harrier.doc.ic.ac.uk...

> For similar situation, I had a script that translates assembly
instructions
> directly to .coe and .mif files and edits the ram initialization in the
.edf.
> In the case of a single block ram, the edit of .edf is quite trivial. If
> you need more than one block, the words will be distributed between the
> rams, which complicates the script a bit, but is also quite doable.
>
> On the other hand, regenerating the .edf is just one click in CoreGen.

Sure, but the functional simulator in Foundation doesn't read the coe, mif,
or edf file.  I'm hoping to find the best possible way to allow the
students to change their program and have those changes show up in both
simulation and hardware.

JP

Josh Pfrimmer <yeah_spam_me@thisaddress.com> wrote:

> In the interest of fully exploring the issue, though (though I may very
> well take your suggestion) How do people cope with the problem below, when
> CoreGen _is_ used?

For similar situation, I had a script that translates assembly instructions
directly to .coe and .mif files and edits the ram initialization in the .edf. 
In the case of a single block ram, the edit of .edf is quite trivial. If 
you need more than one block, the words will be distributed between the 
rams, which complicates the script a bit, but is also quite doable.

On the other hand, regenerating the .edf is just one click in CoreGen.

-- 
T.Rissa
tpr at doc ic ac uk

could do.  How are the Xilinx 4.2 tools at inferring BlockRAM vs.
Distributed RAM?  Are they efficient?

In the interest of fully exploring the issue, though (though I may very
well take your suggestion) How do people cope with the problem below, when
CoreGen _is_ used?

JP

"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3FBA645E.6040804@flukenetworks.com...
> Josh Pfrimmer wrote:
>
> > The first issue I came up against was that they now have to use CoreGen
to
> > make memories (program, data, stack), where we used to use LogicBlox.
> > Specifying memory contents in LogicBlox used a .mem file.  In Coregen,
you
> > have to use a .coe file.  Easy enough, and when I go all the way
through
> > implementation, I have no problems at all.
> >
> > When I want to do a functional simulation, however, the program memory
is
> > all zeroes.  How best to go about getting the .coe data into the
Foundation
> > functional simulator?  The VHDL and verilog files reference a .mif
file.
> > The simulator allows one to "load contents" via a hex file.
>
> Consider using a vector array to infer rom or ram
> and eliminate the coregen simulation hassles.
>
>   -- Mike Treseler
>

Josh Pfrimmer wrote:

> The first issue I came up against was that they now have to use CoreGen to
> make memories (program, data, stack), where we used to use LogicBlox.
> Specifying memory contents in LogicBlox used a .mem file.  In Coregen, you
> have to use a .coe file.  Easy enough, and when I go all the way through
> implementation, I have no problems at all.
> 
> When I want to do a functional simulation, however, the program memory is
> all zeroes.  How best to go about getting the .coe data into the Foundation
> functional simulator?  The VHDL and verilog files reference a .mif file.
> The simulator allows one to "load contents" via a hex file.

Consider using a vector array to infer rom or ram
and eliminate the coregen simulation hassles.

  -- Mike Treseler

Hi experts,

I've looked through the archives, and the Xilinx literature, and haven't
found an answer to this question, so please forgive me if it's obvious
and/or everyone's sick of answering.  I've spent a couple of days on this.

I'm upgrading a lab here at UVic from an xc4000 based board to a Spartan2.
So as not to complicate the upgrade needlessly, we'd like to stick with
Foundation 4.2i tools and design flow.  (We'll upgrade that next semester..
one thing at a time.) The students are to create a pipelined 8-bit
processor in either VHDL or Schematic.  They use the Foundation simulator
to debug.

The first issue I came up against was that they now have to use CoreGen to
make memories (program, data, stack), where we used to use LogicBlox.
Specifying memory contents in LogicBlox used a .mem file.  In Coregen, you
have to use a .coe file.  Easy enough, and when I go all the way through
implementation, I have no problems at all.

When I want to do a functional simulation, however, the program memory is
all zeroes.  How best to go about getting the .coe data into the Foundation
functional simulator?  The VHDL and verilog files reference a .mif file.
The simulator allows one to "load contents" via a hex file.

I'd prefer a solution that only requires students to edit one file to
change the program for both the hardware implementation (I've noticed that
CoreGen puts the correct data in the EDIF file) AND the simulation.  It's a
pretty challenging lab as it is, without the extra pitfall of having
mismatching simulation/hardware programs.

Thanks for your time,

JP

-- 
                Josh Pfrimmer, B.Eng.
_________________________________________
 University of Victoria, ECE
 jpfrimmer<AT>ece<DOT>uvic<DOT>ca
_________________________________________
->My views and opinions are not necessarily UVic's