EDK : FSL macros defined by Xilinx are wrong

[Jim Granville]

Cross posted to comp.arch.fpga, as this is an intersting resource.

Pinhas wrote:

http://bknpk.no-ip.biz/cpu_8051_ver/top.html

#

Stable Design: The design is translated from a VHDL dalton project
http://www.cs.ucr.edu/~dalton/i8051/i8051syn.
#

Small Design: Consumes only 324 Flip-Flops: map report

More map report details, from the link :
Target Device : xc4vlx25
Number of Slice Flip Flops: 324 out of 21,504 1%
Total Number 4 input LUTs: 2,423 out of 21,504 11%

#

Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report

-jg

 

[Nils]

Jim Granville wrote:

Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report

I don't want to nitpick. It looks like a nice and (maybe more important)
little project.

But on the web site I see the following performance figures:

I8051_ALU:

Critical Path Length (ns): 178
Maximum Clock Speed (MHz): 5.63

I have to admit that I'm a FPGA noob, but I think that part deserves
some optimization.

Nils

 

[Symon]

"Nils" <n.pipenbrinck@cubic.org> wrote in message
news:6lnd94Fda23nU1@mid.uni-berlin.de...

Jim Granville wrote:

Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report


I don't want to nitpick. It looks like a nice and (maybe more important)
little project.

But on the web site I see the following performance figures:

I8051_ALU:

Critical Path Length (ns): 178
Maximum Clock Speed (MHz): 5.63

I have to admit that I'm a FPGA noob, but I think that part deserves some
optimization.

Nils

Without reading TFA, I agree, I laughed where it says it's a small design
because it only uses 324 FFs, and yet it uses 10 times as many LUTs!

Cheers, Syms.

 

[Meindert Sprang]

"Nils" <n.pipenbrinck@cubic.org> wrote in message
news:6lnd94Fda23nU1@mid.uni-berlin.de...

Jim Granville wrote:

Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report


I don't want to nitpick. It looks like a nice and (maybe more important)
little project.

But on the web site I see the following performance figures:

I8051_ALU:

Critical Path Length (ns): 178
Maximum Clock Speed (MHz): 5.63

I have to admit that I'm a FPGA noob, but I think that part deserves
some optimization.

And some work too....

Quote:
Limitations:
This implementation is not cycle/timing compatible.
Interrupt handling is not currently implemented.
Peripheral devices are not currently implemented.

Meindert

 

[Pinhas]

On 16 אוקטובר, 08:27, "Meindert Sprang"
<m...@NOJUNKcustomORSPAMware.nl> wrote:

"Nils" <n.pipenbri...@cubic.org> wrote in message

news:6lnd94Fda23nU1@mid.uni-berlin.de...



Jim Granville wrote:

Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report

I don't want to nitpick. It looks like a nice and (maybe more important)
little project.

But on the web site I see the following performance figures:

I8051_ALU:

   Critical Path Length (ns): 178
   Maximum Clock Speed (MHz): 5.63

I have to admit that I'm a FPGA noob, but I think that part deserves
some optimization.

And some work too....

Quote:
Limitations:
  This implementation is not cycle/timing compatible.
  Interrupt handling is not currently implemented.
  Peripheral devices are not currently implemented.

Meindert

As far as I remeber this is a multicycle path. But I'll double check.

 

[KJ]

On Oct 19, 2:45 pm, Jukka Marin <jma...@pyy.embedtronics.fi> wrote:

I would try putting the RAM stuff inside one always block, but it seems a
bit difficult to do.. (or, I still can't think FPGA - my brain always
seems to enter software mode when opening a text editor).

I'd appreciate pointers or examples which would get me unstuck. ;-)

Start around page 13
http://www.altera.com/literature/hb/qts/qts_qii51007.pdf

KJ

 

[Jukka Marin]

On 2008-10-20, KJ <kkjennings@sbcglobal.net> wrote:

Start around page 13
http://www.altera.com/literature/hb/qts/qts_qii51007.pdf

Thanks. I have read this document before, but I noticed something new on
the second time - but still no go. Here are some fragments of my Verilog
source:


`define RXRAMSIZE 16'd2048
`define RXRAMBITS 16'd9

reg [31:0] rx1 [0:`RXRAMSIZE-1] /* synthesis ramstyle = "M9K, no_rw_check" */;

....

reg [`RXRAMBITS-1:0] rx1rptr;
reg [1:0] rx1rbank;
reg [15:0] rx1rlen;
reg [`RXRAMBITS+1:0] rx1b;
reg [`RXRAMBITS+1:0] rx1i;

always @(negedge rd) begin // MCU bus read
if ((cs == 0)) begin
case (a << 2)
...
`REG_RX1LEN: begin
if (rx1rptr == 0) begin
// start a read if data available
rx1rlen = rx1[rx1b][15:0];
if (rx1rlen != 0) begin
rx1rptr = 1;
end
end
dout = rx1rlen;
end

`REG_RX1DATA: begin
if (rx1rptr != 0) begin
// read operation in progress
dout = rx1[rx1i];
rx1rptr = rx1rptr + 1'b1;
if (rx1rptr > rx1rlen) begin
// end of data, move to next bank
rx1rptr = 0;
rx1rbank = rx1rbank + 2'b1;
end
rx1b = rx1rbank << `RXRAMBITS;
rx1i = {rx1rbank, rx1rptr};
end else begin
// no more data
dout = 0;
end
end
endcase
end
end

.....

reg [`RXRAMBITS-1:0] rx1wptr;
reg [1:0] rx1wbank;
reg [55:0] fbrx1_flag;
reg [32:0] fbrx1_shifter;
reg [15:0] fbrx1_wordcount;

always @(posedge fbrxc or posedge softreset) begin
if (softreset) begin
rx1wptr = 0;
rx1wbank = 0;
fbrx1_flag = 0;
end else begin
if (fbrx1_wordcount == 0) begin
// searching for start flag
fbrx1_flag = {fbrx1_flag[54:0], fbrxd};
if (fbrx1_flag[55:24] == `FIBER_FLAG) begin
fbrx1_wordcount = fbrx1_flag[15:0];
fbrx1_flag = 0;
fbrx1_shifter = 33'b1;
rx1wptr = 1;
rx1[rx1wbank << `RXRAMBITS] = 0;
end
end else begin
fbrx1_shifter = {fbrx1_shifter[31:0], fbrxd};
if (fbrx1_shifter[32] == 1) begin
rx1[{rx1wbank,rx1wptr}] = fbrx1_shifter[31:0];
fbrx1_shifter = 33'b1;
rx1wptr = rx1wptr + 1'b1;
if (rx1wptr > fbrx1_wordcount) begin
rx1[rx1wbank << `RXRAMBITS] = fbrx1_wordcount;
fbrx1_wordcount = 0;
rx1wbank = rx1wbank + 2'b1;
end
end
end
end
end



I'm trying to receive 32-bit words (bits clocked in on the rising edge of
fbrxc and stored in a 33-bit shift register) and store the data in rx1[],
rx1[0] is supposed to hold the frame length (received after the start flag).
There are four fixed banks in the rx1 buffer, the banks are accessed by
the rx1wbank register.

The first always@() block is part of the MCU bus interface; the MCU reads
the frame length from the REG_RX1LEN register and data from REG_RX1DATA.
The code is not finished yet, I'd like to make it compile before putting
more effort in it.

This is my very first FPGA project, so I may be doing something in the
completely wrong way. I have been working on hardware and software for
more than 20 years, but I'm afraid I haven't learned how to think the
FPGA way yet. I wish I had someone to teach me Verilog and FPGA, but
the "local" Altera FAE has only been using VHDL and hasn't been able to
help too much.

So, is there anything correct in my code? ;-) Thanks!

-jm

 

[Mike Treseler]

On 2008-10-20, KJ <kkjennings@sbcglobal.net> wrote:
Start around page 13
http://www.altera.com/literature/hb/qts/qts_qii51007.pdf
That is a nice reference.

Jukka Marin wrote:

The code is not finished yet, I'd like to make it compile before putting
more effort in it.

Most designers would use a simulator to debug this code.
A simulator will help with the syntax errors *and*
with logical problems.

So, is there anything correct in my code? ;-) Thanks!

The only way to find out is to add a module interface
and run a sim. When I get stuck, I go back and start
with a related, working example (maybe from the reference above)

I have been working on hardware and software for
more than 20 years, but I'm afraid I haven't learned how to think the
FPGA way yet.

Here's a hint. The execution environment
for verilog and vhdl code is a simulator.

-- Mike Treseler

 

[LittleAlex]

On Oct 19, 11:45 am, Jukka Marin <jma...@pyy.embedtronics.fi> wrote:

Hi,

I started learning FPGA's and Verilog and seem to run into problems every
day

I'm trying to use dual-port RAM for buffering data between a serial link
and a 32-bit CPU bus. I wrote two separate always blocks, one which
receives data from the serial link and writes it in RAM and another one
which talks to the CPU bus and allows reading of the RAM.

When I try to compile this design (using quartus ii), the compiler "never"
finishes and I believe it's trying to build the RAM array out of logic
gates. If I make the RAM small enough, the compiler succeeds (although
it takes a long time).

I did a similar thing for serial link transmission and it worked as expected
(and the compiler used real RAM for the buffer, not logic gates).

Is it wrong to access the same memory in two separate always blocks? The
serial link and the CPU bus are independent and the bus has no clock, so
I'm trying to make an async design. I'm getting no error messages about
RAM from the compiler, so I'm not sure what I'm doing wrong. (Quartus II
is usually pretty verbose, complaining about everything from unused pins
to the color of my socks, but this time it isn't helping at all.)

I would try putting the RAM stuff inside one always block, but it seems a
bit difficult to do.. (or, I still can't think FPGA - my brain always
seems to enter software mode when opening a text editor).

I'd appreciate pointers or examples which would get me unstuck. ;-)

Thanks,

-jm

I can't see your code, but I can imagine that Quartus would have a
hard time with the memory split between two blocks.

Two things to try:
1) Make the memory very very small, (small enough to complete) and
look at the results.
2) Instantiate a dual port memory directly, get the rest of the code
working, then go back and try inferred RAM.

Alex.

 

[Kai Kärkkäinen]

Sähkö [Jukka Lukkari, 14.05.2008]

Sähkön kulutus jatkaa laskuaan
Sähkön kulutus jäi huhtikuussa runsaan prosentin edellisvuotta pienemmäksi.
Vuoden neljän ensimmäisen kuukauden aikana sähköä on Suomessa kulunut 32,3
gigawattituntia eli yli kaksi prosenttia viime vuotta vähemmän.

Aika hurjaa pudotusta kun enmnakoitiin viiko sitten teolisuuspiireissämme
mitä löie +10% lisää ja nyt tuo väittää jo -6% vuosilaskua!!! Kuka siis
valehtelee maasamme ydinhallinnon lisäksi?!

 

[Olavi Rantala]

MYRTYNEITÄ ydinherraskaisia.

YLE 8.5.2008. Haastateltavan energiaherran suusta: "Olemme joutuneet
huomaamaan, ettemme kovista yrityksistämme huolimatta kyenneet vakuuttamaan
Suomen kansalle ydinvoiman tarpeellisuutta lainkaan!" .. ..

Ja melkein itkua vääntävää ydinlobbariherraa yksi toisensa perään
kuvaruutuun enemmän kuin harminsa kiukkua nieleskellen. Eikä mairitteluun
todella ole syytä. Suomen kansa oli pannut karut faktat esiin. Gallupin
mukaan vain 20 % oli ylipäätään edes yhtä ydinvoimalaa halukas rakentamaan.
Teollisuuspiirien himoitseman triplan ydinhankke- emieliin peilaili 4 %
kannatus! Eikä edes ydinalan OL-3 plutoniumpoltolle ja
isotooppiuraanikaivoshankkeille uraanirikastamoineen välttämättömän
NATO-jäsenyyden suosio ole ylittänyt 20 % pöyristyttävän pientä
kannatusnyanssiaan kovasta, megalomaanisesta painostuksesta piittaamatta.
Toki jo Niinistön pitämän nuorisoparlamentin 80 % ydinvastaisuuden kanssa
kaikki kivasti stemmaa.

Ehkä silti kaikkein tärkein on yhä sanomatta. Nimittäin tuollaisilla
ydinprojektiensa tahkoamilla kannatusluvuilla on päivän selvä viesti niin
ydinintoisille puolueille yleensä, kun erityisesti ydinryvettyneelle
Kokoomukselle, KTM:lle kuin ihan koko tulevan hallituskuvion varmennukseksi.
Jokainen joka tällaisiin lukuihin luo ydinhankkeitaan tietää tarkoin, että
kansa viskaa vaaleissa oppositioon takuuvarmasti JOKAISEN
ydinkannatuspuolueen ministeriöineen!..

Ei siis mikään ihme, että ydinherrojen rasvaiset hikivanat kasvavat vaalien
lähetessä. Ei lupaa muuten jatkossa ruusutarhoja yhdelle sun muille
ydinyhtiömonopoleillemme. Ja HYVÄ NIIN!)

 

[jleslie48]

On Jan 21, 10:53 am, "jeffrey.johnson" <j...@fpgadeveloper.com> wrote:

You will find beginner tutorials for the XUPV2P board on the FPGA Developer
website:

http://www.fpgadeveloper.com

Specifically for getting RS232 communications working, try the "Base
System Builder" tutorial.

Yes, I looked at that example. It uses the powerPC which I don't
believe I have access to,
my project is supposed to use the xc2vp30 only and not another
chipset, or did I just say something really stupid (ie, I don't have a
clue what the powerpc is, and is it part of the the xc2vp30?)

 

[Brian Drummond]

On Wed, 21 Jan 2009 09:44:11 -0800 (PST), jleslie48
<jon@jonathanleslie.com> wrote:

On Jan 21, 10:53 am, "jeffrey.johnson" <j...@fpgadeveloper.com> wrote:
You will find beginner tutorials for the XUPV2P board on the FPGA Developer
website:

http://www.fpgadeveloper.com

Specifically for getting RS232 communications working, try the "Base
System Builder" tutorial.

Yes, I looked at that example. It uses the powerPC which I don't
believe I have access to,
my project is supposed to use the xc2vp30 only and not another
chipset, or did I just say something really stupid (ie, I don't have a
clue what the powerpc is, and is it part of the the xc2vp30?)

There are 2 PowerPCs in the xc2vp30; you can use them or ignore them as
you wish. If you are following an example EDK project (like that one) it
will take the pain out of using them; deviate much from the example and
things can get very confusing very fast.

My first experience with the EDK system; I stepped off the path, simply
to change the input clock from the example I was following, and it took
me nearly a week to get the project to build again and communicate at
the right baud rate!

The block of hardware it produces (PPC, program&data memory, bus, bus
master, bus slave interfaces, interrupt logic, etc, and finally a UART)
will be at least a hundred times more complex than a simple RS232 UART
and a state machine to feed it "hello world". (And probably no more time
to generate; if you strictly follow the path) But it will run C.

Your choice. But once you get used to hardware the PPC will seem
painfully slow.

- Brian

 

[whygee]

Hi Rick !

this is the rest of the discussion from comp.arch.embedded.

rickman wrote:

Have you considered a different family? There is a $40 Xilinx eval
board available from Avnet. But it still does not have ram. That
will likely be a $200 or higher board.
I'm already satisfied with what I got from Actel

("it works and has what i want")
and I bet that any issue I'll have with SDRAMs
will not be related to the FPGA family itself,
but rather, come from my misunderstanding of the
SDRAM's datasheets or something stupid like that...

I have a 2nd hand Altera (NIOS) board (without support tools)
and a pair of XCV400 waiting for a suitable PCB, and I look around
for other vendors. But I don't want to be diverted/distracted from
actual development itself : either I spend my time and money
evaluating vendors, or I do something with what I already have...
Guess which one eventually brings money home

The only hard part is the wiring. A decoupling cap will need to be
wired directly between the power and ground pins.
of course. I just got some really cool ultra-miniature high-capacity ceramic

capacitors and that's where they are suitable

Actually, this may
be a show stopper. The low impedance of the ground plane and its
capacitance helps a lot to reduce the high freq spikes on the power
bus. By wiring power it is possible to add too much inductance and
the cap may not be able to provide a low enough impedance.
adding capacity and reducing impedance is not an issue,

I can use larger diameter wires at will
and my collection of capacitors is still growing

As long as your wires are very short (both on board and off board),
less than 2" for example, the SI and clock timing will not be
significant issues. To mitigate the output delays on the FPGA you
should register all signals in the IOBs.
of course. I always latch outputs.

Also my designs don't clock faster than 100MHz, and I thought
that it's possible to downclock SDRAM chips, provided the cycles
are adjusted.

That will work. You can clock an SDRAM as slow as you want to some
point. You do have to provide a periodic refresh cycle unless you are
doing that in software. But the clock speed won't have much to do
with the SI and power decoupling issues.

My fear is that my dear 475 'scope is limited to 200MHz so I could
miss things. But that will come later, when going "high speed" on PCB,
since the SDRAM initialisation dance in itself looks scary...
I'll probably have to finish my small CPU core before I go further,
since a programmed sequence will spare me the effort to design
a (scary) FSM.

<afterthought>

And if the SDRAM can be clocked as slowly as one wants,
then I could even "prototype" the SDRAM interface
with "bitbang"-like software, and then move slowly from
soft to VHDL as it starts to work...

You also need an SDRAM controller inside the FPGA, parameterised to your
particular SDRAM chips.
Sure, I'm looking at datasheets and VHDL "cores" too.

Should this discussion continue on comp.arch.fpga ?

That would be a good venue.
so here we go.

I have not found a good venue for discussing FPGA CPU cores.
Note that the request is (was) independent of YASEP,

I've just unearthed some /old/ DSP projects that were
still out of my reach 6 months ago.
However it seems that I'll need at least a small CPU
to get the thing working (both the SDRAM and the DSP).
This encourages me to continue with YASEP

If you are interested in MISC processors,
comp.lang.forth is a good place.

However YASEP is not MISC, it's just "small"
But Forth and the likes are definitely worth caring.

Furthermore, I believe that since I'll have to use SDRAM anyway
one day, then I should hit the bullet and go forward.
You can get the Altera softare for free just like the Xilinx software.
I'm investigating that but I don't give Altera high priority,

since they force me on Windows. Unless someone thinks that
"or else pay $2500 for your linux license" means something else.

OK I confess that I use Actel's suite under Vista (ouch)
but at least there is still the possibility to use the
Linux version (in some ... way). I'm investigating it now...

The programming cable is not a lot of money.
I consider making my own,

once I have time and all the SW issues solved.

I would bite
the bullet and use that for a first pass. Wiring an SDRAM chip is
likely to delay you some considerable time.

I have to balance several things :
- the time and cost of acquiring, installing, configuring, using, mastering
yet another vendor's tools, and getting around its specific gotchas
- the potential dangers of using a single vendor's products
- the actual usefulness, price, and reward of each particular project
(and the SDRAM is not a necessity now).

It looks like a "dirty hack" with 25mil wires from IDE cables
is the fastest, cheapest and easiest way now.
Maybe it won't work but it will probably help me
understand and get a first foot in the sh^Wmatter...

Regards,

Rick
yg

--
http://ygdes.com / http://yasep.org

 

[rickman]

On Jan 21, 9:15 pm, whygee <why...@yg.yg> wrote:

Hi Rick !

this is the rest of the discussion from comp.arch.embedded.

rickman wrote:
Have you considered a different family? There is a $40 Xilinx eval
board available from Avnet. But it still does not have ram. That
will likely be a $200 or higher board.

I'm already satisfied with what I got from Actel
("it works and has what i want")
and I bet that any issue I'll have with SDRAMs
will not be related to the FPGA family itself,
but rather, come from my misunderstanding of the
SDRAM's datasheets or something stupid like that...

I have a 2nd hand Altera (NIOS) board (without support tools)
and a pair of XCV400 waiting for a suitable PCB, and I look around
for other vendors. But I don't want to be diverted/distracted from
actual development itself : either I spend my time and money
evaluating vendors, or I do something with what I already have...
Guess which one eventually brings money home

I am of the opinion that with the top three FPGA vendors, Xilinx,
Altera and Lattice, there is not a lot to "evaluate". Each vendor has
at least one high end line that is fast, dense and has lots of bells
and whistles. They also have at least one line of economy chips that
are cheap and yet still very capable. Unless you are planning to push
the limitations of any of these chips, what is there to evaluate? I
didn't get the impression that this is about a product, so if you are
just using this as a learning tool, what basis do you have for
evaluation? What is your criteria? I know that I would choose the
device that is easiest to prototype with and later worry about that
device I want to use in a product.

BTW, when you say you have no support tools for the Altera device, I
think i told you that the Altera FPGA tools are available free.

The only hard part is the wiring. A decoupling cap will need to be
wired directly between the power and ground pins.

of course. I just got some really cool ultra-miniature high-capacity ceramic
capacitors and that's where they are suitable

Actually, this may
be a show stopper. The low impedance of the ground plane and its
capacitance helps a lot to reduce the high freq spikes on the power
bus. By wiring power it is possible to add too much inductance and
the cap may not be able to provide a low enough impedance.

adding capacity and reducing impedance is not an issue,
I can use larger diameter wires at will
and my collection of capacitors is still growing

The wire diameter has very little to do with the impedance. Any
capacitor you use has impedance. You can see this very clearly if you
look at the impedance-frequency curves for the parts. The resonant
frequency tells you the frequency at which the capacitive and
inductive impedance are equal. As the frequency continues to increase
the impedance rises. For a high speed design the impedance of the cap
becomes significant at frequencies that are important. That is why
power planes are used. They provide a low impedance at frequencies
into the GHz range.

Then there is ground bounce. Your wiring will just add to that
problem.

As long as your wires are very short (both on board and off board),
less than 2" for example, the SI and clock timing will not be
significant issues. To mitigate the output delays on the FPGA you
should register all signals in the IOBs.

of course. I always latch outputs.

Also my designs don't clock faster than 100MHz, and I thought
that it's possible to downclock SDRAM chips, provided the cycles
are adjusted.

That will work. You can clock an SDRAM as slow as you want to some
point. You do have to provide a periodic refresh cycle unless you are
doing that in software. But the clock speed won't have much to do
with the SI and power decoupling issues.

My fear is that my dear 475 'scope is limited to 200MHz so I could
miss things. But that will come later, when going "high speed" on PCB,
since the SDRAM initialisation dance in itself looks scary...
I'll probably have to finish my small CPU core before I go further,
since a programmed sequence will spare me the effort to design
a (scary) FSM.

afterthought

And if the SDRAM can be clocked as slowly as one wants,
then I could even "prototype" the SDRAM interface
with "bitbang"-like software, and then move slowly from
soft to VHDL as it starts to work...

That will be interesting. There are limits to how slow it can run,
check the data sheet. The initialization is not all that bad, at
least if you are using SDRAM. I did one of those some 10 years ago.
I just made a FSM and it worked the first time. I did find a lot of
good app notes and data sheets at Micron Semi. I don't know if they
are still available. I have them in print form. 8^*

You also need an SDRAM controller inside the FPGA, parameterised to your
particular SDRAM chips.
Sure, I'm looking at datasheets and VHDL "cores" too.

Should this discussion continue on comp.arch.fpga ?

That would be a good venue.

so here we go.

You can also cross post to both groups.

I have not found a good venue for discussing FPGA CPU cores.

Note that the request is (was) independent of YASEP,
I've just unearthed some /old/ DSP projects that were
still out of my reach 6 months ago.
However it seems that I'll need at least a small CPU
to get the thing working (both the SDRAM and the DSP).
This encourages me to continue with YASEP

If you are interested in MISC processors,
comp.lang.forth is a good place.


However YASEP is not MISC, it's just "small"
But Forth and the likes are definitely worth caring.

YASEP... Yet Another Small Embedded Processor? I feel the same way
about mine. I designed a CPU some 8 years ago based on the Forth
model. It turned out remarkably similar to Bernd Paysan's b16, but
with very different instruction format. From the work I have done, it
appears that the data path will dominate the size of the design. Then
the efficiency is determined by how well your instruction set uses
parallelism in the data path. There is another project called the ZPU
that is trying to design a processor that can be implemented in as
small a footprint as possible and also be capable of implemented as a
high speed version while being binary compatible. It is also stack
based, but supported with a C compiler.

There is a lot to learn by working with someone else's design. I
guess I am saying you can learn a lot more from someone else than you
can by yourself.

Furthermore, I believe that since I'll have to use SDRAM anyway
one day, then I should hit the bullet and go forward.
You can get the Altera softare for free just like the Xilinx software.

I'm investigating that but I don't give Altera high priority,
since they force me on Windows. Unless someone thinks that
"or else pay $2500 for your linux license" means something else.

OK I confess that I use Actel's suite under Vista (ouch)
but at least there is still the possibility to use the
Linux version (in some ... way). I'm investigating it now...

The programming cable is not a lot of money.

I consider making my own,
once I have time and all the SW issues solved.

I'll let this whole can of worms alone. There is another thread about
using Windows or more specifically, Vista. It is getting long winded
and the more radical elements are coming out.

I would bite
the bullet and use that for a first pass. Wiring an SDRAM chip is
likely to delay you some considerable time.

I have to balance several things :
- the time and cost of acquiring, installing, configuring, using, mastering
yet another vendor's tools, and getting around its specific gotchas
- the potential dangers of using a single vendor's products
- the actual usefulness, price, and reward of each particular project
(and the SDRAM is not a necessity now).

It looks like a "dirty hack" with 25mil wires from IDE cables
is the fastest, cheapest and easiest way now.
Maybe it won't work but it will probably help me
understand and get a first foot in the sh^Wmatter...

Man, you *are* a masochist! Good luck.

--http://ygdes.com/http://yasep.org

I took a look. I'm just curious, why are you designing your own
processor? I assume you are aware that there are literally dozens of
other processors out there... hence the name.

Rick

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:
(snip, someone wrote)

adding capacity and reducing impedance is not an issue,
I can use larger diameter wires at will
and my collection of capacitors is still growing

The wire diameter has very little to do with the impedance.

Wire diameter is related to inductance, though.
And inductance is related to impedance...

Any capacitor you use has impedance. You can see this
very clearly if you look at the impedance-frequency
curves for the parts. The resonant frequency tells you the
frequency at which the capacitive and inductive impedance
are equal. As the frequency continues to increase
the impedance rises. For a high speed design the impedance of the cap
becomes significant at frequencies that are important. That is why
power planes are used. They provide a low impedance at frequencies
into the GHz range.

-- glen

 

[Martin Thompson]

rickman <gnuarm@gmail.com> writes:

On Jan 21, 9:15 pm, whygee <why...@yg.yg> wrote:
Hi Rick !

this is the rest of the discussion from comp.arch.embedded.

My fear is that my dear 475 'scope is limited to 200MHz so I could
miss things. But that will come later, when going "high speed" on PCB,
since the SDRAM initialisation dance in itself looks scary...
I'll probably have to finish my small CPU core before I go further,
since a programmed sequence will spare me the effort to design
a (scary) FSM.

If it helps descarify things, my first SDRAM controller (in an Altera
10KE) worked first time at 100MHz (on a PCB admittedly, which I also
designed). No scope required - although I had lots of testpoints on,
which always reduces the chance of needing them .

I did spend quite a while in Modelsim before heading benchwards
though!

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[John Adair]

I'm not sure if you just want a module with 2.54mm pins or a
development board with SDRAM but we can offer both.

For a module we dil header style SDRAM modules. These are out of stock
just now but should be available in a few weeks. These modules are
aimed at our Raggedstone range range of boards.

In the development board area we have Darnaw1 http://www.enterpoint.co.uk/moelbryn/darnaw1.html
which currently has 128Mbit SDRAM on as standard but we have a batch
going through shortly where we are looking at increasing the SDRAM and
SPI Flash sizes on the XC3S1600E versions.

There is also a new product coming that is very much aimed at
microprocessor applications based in FPGA and that will have 256Mbit
SDRAM in a X32 organisation and has capability to go to 512Mbit. I'm
expecting to announce this properly in 3-4 weeks time when have run
some tests on it.

John Adair
Enterpoint td.


On 22 Jan, 02:15, whygee <why...@yg.yg> wrote:

Hi Rick !

this is the rest of the discussion from comp.arch.embedded.

rickman wrote:
Have you considered a different family?  There is a $40 Xilinx eval
board available from Avnet.  But it still does not have ram.  That
will likely be a $200 or higher board.

I'm already satisfied with what I got from Actel
("it works and has what i want")
and I bet that any issue I'll have with SDRAMs
will not be related to the FPGA family itself,
but rather, come from my misunderstanding of the
SDRAM's datasheets or something stupid like that...

I have a 2nd hand Altera (NIOS) board (without support tools)
and a pair of XCV400 waiting for a suitable PCB, and I look around
for other vendors. But I don't want to be diverted/distracted from
actual development itself : either I spend my time and money
evaluating vendors, or I do something with what I already have...
Guess which one eventually brings money home

The only hard part is the wiring.  A decoupling cap will need to be
wired directly between the power and ground pins.

of course. I just got some really cool ultra-miniature high-capacity ceramic
capacitors and that's where they are suitable

 Actually, this may
be a show stopper.  The low impedance of the ground plane and its
capacitance helps a lot to reduce the high freq spikes on the power
bus.  By wiring power it is possible to add too much inductance and
the cap may not be able to provide a low enough impedance.

adding capacity and reducing impedance is not an issue,
I can use larger diameter wires at will
and my collection of capacitors is still growing

As long as your wires are very short (both on board and off board),
less than 2" for example, the SI and clock timing will not be
significant issues.  To mitigate the output delays on the FPGA you
should register all signals in the IOBs.

of course. I always latch outputs.

Also my designs don't clock faster than 100MHz, and I thought
that it's possible to downclock SDRAM chips, provided the cycles
are adjusted.

That will work.  You can clock an SDRAM as slow as you want to some
point.  You do have to provide a periodic refresh cycle unless you are
doing that in software.  But the clock speed won't have much to do
with the SI and power decoupling issues.

My fear is that my dear 475 'scope is limited to 200MHz so I could
miss things. But that will come later, when going "high speed" on PCB,
since the SDRAM initialisation dance in itself looks scary...
I'll probably have to finish my small CPU core before I go further,
since a programmed sequence will spare me the effort to design
a (scary) FSM.

afterthought

And if the SDRAM can be clocked as slowly as one wants,
then I could even "prototype" the SDRAM interface
with "bitbang"-like software, and then move slowly from
soft to VHDL as it starts to work...

You also need an SDRAM controller inside the FPGA, parameterised to your
particular SDRAM chips.
Sure, I'm looking at datasheets and VHDL "cores" too.

Should this discussion continue on comp.arch.fpga ?

That would be a good venue.

so here we go.

I have not found a good venue for discussing FPGA CPU cores.

Note that the request is (was) independent of YASEP,
I've just unearthed some /old/ DSP projects that were
still out of my reach 6 months ago.
However it seems that I'll need at least a small CPU
to get the thing working (both the SDRAM and the DSP).
This encourages me to continue with YASEP

If you are interested in MISC processors,
comp.lang.forth is a good place.


However YASEP is not MISC, it's just "small"
But Forth and the likes are definitely worth caring.

Furthermore, I believe that since I'll have to use SDRAM anyway
one day, then I should hit the bullet and go forward.
You can get the Altera softare for free just like the Xilinx software.

I'm investigating that but I don't give Altera high priority,
since they force me on Windows. Unless someone thinks that
"or else pay $2500 for your linux license" means something else.

OK I confess that I use Actel's suite under Vista (ouch)
but at least there is still the possibility to use the
Linux version (in some ... way). I'm investigating it now...

 The programming cable is not a lot of money.

I consider making my own,
once I have time and all the SW issues solved.

 I would bite
the bullet and use that for a first pass.  Wiring an SDRAM chip is
likely to delay you some considerable time.

I have to balance several things :
  - the time and cost of acquiring, installing, configuring, using, mastering
    yet another vendor's tools, and getting around its specific gotchas
  - the potential dangers of using a single vendor's products
  - the actual usefulness, price, and reward of each particular project
     (and the SDRAM is not a necessity now).

It looks like a "dirty hack" with 25mil wires from IDE cables
is the fastest, cheapest and easiest way now.
Maybe it won't work but it will probably help me
understand and get a first foot in the sh^Wmatter...

Regards,> Rick

yg

--http://ygdes.com/http://yasep.org

 

[jleslie48]

On Jan 21, 7:59 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

Your choice. But once you get used to hardware the PPC will seem
painfully slow.

- Brian

That's half the reason I have to abandon my TI6713 DSP platform and
move to a FPGA only environment.

 

[olliH]

I want to write a function to
1) convert single precision 32 bit floating point number to integer
and return integer
2) convert integer to single precision floating point number and
return 32 bit floating point

What are the parameters I should give to each functions and what logic
do I use for both the functions.

Do i need to write seperate function for signed and unsigned numbers?

Your help would be appreciated

You can use the Xilinx floating point operator.

http://www.xilinx.com/products/ipcenter/FLOATING_PT.htm