EDK : FSL macros defined by Xilinx are wrong

[Nial Stewart]

I'm intrigued by your answer, but don't fully understand what you
propose.

You need to have a better understanding of what's generated by your code.
Remember you're describing hardware.

My last serial generating module has a big 256 vector input that it is
translating to a serial output that repeats the 256 bits over and
over. The code is basically something like this:
input [255:0] invector;
output serout;
reg [7:0] x;
always @(negedge shiftclock)
begin
x = x + 1;
serout = invector[x];
end

That (probably) creates a 256 bit vector and a massive mux to select
one of the bits.

In VHDL the following generates a big shift register which the tools
will find dead easy to place and route as each logical path is just
from one register to the next.....

if(rising_edge(clk)) then

invector(254 downto 0) <= invector(255 downto 1);
serout <= invector(0);

end if;

This should be easily translated to verilog.




Nial.

 

[Sandeep Dutta]

Hi,

You might want to take a look at
http://www.eecs.berkeley.edu/~alanmi/abc/
you can download the source, for research
purposes this might be what you need.

--Sandeep

 

[Nico Coesel]

Johann Glaser <glaser@ict.tuwien.ac.at> wrote:

Hi!

My PhD thesis deals with coarse-grained reconfigurable logic. Therefore
the RTL schematic synthesis result is one major input for my work.

I tried Xilinx ISE 10.1 as well as Synplicity Synplify Pro 9.2. Both
tools provide this RTL netlist (before implementing it to the technology
netlist), but both in encrypted file formats.

Xilinx ISE 10.1 saves the file as NGR file. Unfortunately there is no
ngr2edif tool provided (while an ngc2edif is available).

Synplicity Synplify Pro 9.2 saves a SRS file and provides an edf2srs
tool, but no reverse.

Could you please point me to tools which can convert these files formats
to open formats (especially EDIF) or to synthesis tools (not necessarily
for FPGA, a tool from an ASIC flow is ok too), which save the RTL
schematic as open file formats.

Why not export to VHDL? It can be regarded as some sort of netlist and
probably converted to EDIF as well.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

 

[Icky Thwacket]

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:noudnebAM4mhCAHVnZ2dnUVZ_qTinZ2d@comcast.com...

I was wondering not so long ago about doing PC board design
in verilog.

I think you can just restrict what you allow. There is much
that could be written in verilog that current synthesis tools
won't allow. (FF's that work on both edges of the clock,
as an example.) I would say that you should allow all
forms of wiring, but restrict what can be connected to
those wires.

-- glen

Brilliant idea!

I also thought of extending the idea to artwork, whereas instead of having
a boring masterpiece hanging on the wall, you could wallpaper the entire
room with an HDL description.

Icky

 

[Andrew Lohbihler]

Dan,

Any Uart EDIF provided by Xilinx can be clocked at 24 Mhz divided by 13 to
get a suitable clock input to that Uart running at 115200. I usually do this
with 48Mhz divided by 26 to get the required clock for 115200. Note that 24
Mhz divided by 13 is 1.846 MHz which is very close to 115200*16 = 1.843 MHz
which is within 1% of the desired clock speed to operate the uart for
115200.

-Andrew


"Dan Arik" <DanA@hotmail.com> wrote in message news:g11ia0$c2l$1@aioe.org...

Hi

I have an evaluation board with a target and a control FPGA. The control
FPGA is connected to the target FPGA over 32-bit local bus and can write
the data to a host PC over a RS232 interface. Both FPGAs are internally
clocked with 24MHz. So I have to implement on the control FPGA a
transmitter that gathers the 32 bits and sends them in 8 bit chunks to
the host PC. I wonder if somebody has some helpful ressources how to
implement such an simple interface. Also I have to implement a suitable
divisor for the baudgenerator to generate 115200 Hz from 24MHz.

Would be thankful for helpful comments and ressources

Dan!

 

[KJ]

"sid" <sylvestersn@yahoo.com> wrote in message
news:2059f53b-6bb3-4552-b918-a4fecaff421b@k30g2000hse.googlegroups.com...

I'm working with a Spartan FPGA using ISE. I have a large array of 8
bit numbers, but due to the nature of the device, some of them are not
used. Is there a way to eliminate those particular registers so that
they don't take up space?

For example, if I have an array with 100 8-bit registers like this:

reg [7:0] array [99:0];

and I'm not using registers [22], [45], [66], or [92], can I somehow
remove those registers from the final design?

Synthesis will automatically do that for you

KJ

 

[Symon]

KJ wrote:

"sid" <sylvestersn@yahoo.com> wrote in message
news:2059f53b-6bb3-4552-b918-a4fecaff421b@k30g2000hse.googlegroups.com...
I'm working with a Spartan FPGA using ISE. I have a large array of 8
bit numbers, but due to the nature of the device, some of them are
not used. Is there a way to eliminate those particular registers so
that they don't take up space?

For example, if I have an array with 100 8-bit registers like this:

reg [7:0] array [99:0];

and I'm not using registers [22], [45], [66], or [92], can I somehow
remove those registers from the final design?


Synthesis will automatically do that for you

KJ

KJ,
In some circumstances, maybe, but look at this scenario:-



process(clk,res)
begin
if res = '1' then
registers <= all_zeros;
elsif rising_edge(clk) then
registers(cpu_address) <= data_from_cpu;
end if;
end process;

data_to_cpu <= registers(cpu_address);



How does the synthesiser know which addresses the CPU never uses?

Cheers, Syms.

 

[KJ]

"Symon" <symon_brewer@hotmail.com> wrote in message
news:g7kioq$3ld$1@aioe.org...

KJ wrote:
"sid" <sylvestersn@yahoo.com> wrote in message
news:2059f53b-6bb3-4552-b918-a4fecaff421b@k30g2000hse.googlegroups.com...

and I'm not using registers [22], [45], [66], or [92], can I somehow
remove those registers from the final design?


Synthesis will automatically do that for you

KJ

KJ,
In some circumstances, maybe, but look at this scenario:-



process(clk,res)
begin
if res = '1' then
registers <= all_zeros;
elsif rising_edge(clk) then
registers(cpu_address) <= data_from_cpu;
end if;
end process;

data_to_cpu <= registers(cpu_address);



How does the synthesiser know which addresses the CPU never uses?

It doesn't, and your example is not one where the registers are not used
either since they are all addressable therefore they must all be
implemented. If this is what the OP had in mind when he said he had
'unused' registers then he is mistaken as well.

KJ

Cheers, Syms.

 

[KJ]

"Zhane" <me75@hotmail.com> wrote in message
news:4b0f65af-207b-41d6-836d-378947084936@b30g2000prf.googlegroups.com...

However, the amount of data that I managed to store inside, seems to
be way lesser than 368,640bits. Even before reach 100,000bits, the
FIFO output a write_full signal, telling me that it's full.

1. How did you validate the actual number of fifo writes that you performed?
Presumably your counter is counting more than once for each time that you
think you do a write.
2. What causes the fifo to be written to? Is that signal generated
synchronously to the same clock that clocks the fifo?

I've no other cores, except my own code. Are there any other mechanism
that uses the blockram even though it is not indicated on the Summary
page inside my Xilinx ISE?

1. Start with a simulation, get that working.
2. Validate that the inputs to the simulation of the device match what is
happening on the actual device

Since your code is implementing the fifo, keep in mind that the fifo signal
is *saying* that the fifo is full, it might not in fact be *full*. Memory
does not send out a signal indicating that it is full, logic that counts
events does.

KJ

 

[Ben Jackson]

On 2008-08-10, News <News@News.com> wrote:

I have the docs on the panel, it is a 1366 x 768 40" LCD from a tv. It
uses 4 lvds pairs @ 80 mhz. I have the datasheet for the panel. They
used a THC63LVDM83R in the tv to do the lvds connection to the panel,

I did something similar with a 42" plasma display. The original driver
was based on an embedded PC that had FPD-Link output, which is a standard
similar to what you describe for getting video data over a flex cable in
a laptop hinge. It used a DS90CF384 decoder because the panel takes.
direct 24-bit parallel RGB. If you google your part you'll see close
relatives of that named as alternates for your Thine part, so I bet your
protocol is identical to FPD-Link, which has many driver options. If I
remember right, 4-wire (clk + 3) is for 16-bit.

The other option is to implement your own encoder in the FPGA, which will
save you pins.

--
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

 

[Symon]

KJ wrote:

It doesn't, and your example is not one where the registers are not
used either since they are all addressable therefore they must all be
implemented. If this is what the OP had in mind when he said he had
'unused' registers then he is mistaken as well.

KJ

KJ,
You miss the point. How do I tell the synthesiser to ignore registers I'm
not going to use?
Cheers, Syms.

 

I've acquired a spartan 3e starter board, and have completed some of the
simpler tasks on fpga4fun.com. I am looking for some guidance on how
to implement LVDS to control a LCD panel.

I have the docs on the panel, it is a 1366 x 768 40" LCD from a tv. It
uses 4 lvds pairs @ 80 mhz. I have the datasheet for the panel. They
used a THC63LVDM83R in the tv to do the lvds connection to the panel,
but I am having no luck sourcing one. So I am wondering if I can do
without and if anyone has happened to have had experience doing so.

You can proberbly use another LVTTL -> LVDS transmitter chip. Just pay
attention to number of bits and lanes.

The Spartan-3E is capable of transmitting LVDS on it's own. The bitrate is
limited however to ~500-600 Mbps per differential pair. And the developer
board needs a jumper setting to use 2.5V or such I think.
There's a datasheet explicitly on using LVDS with Spartan chips from Xilinx.

Bitstream format is also a bit backwards, but not a big deal.

Please keep us posted on any progress

 

[KJ]

"Symon" <symon_brewer@hotmail.com> wrote in message
news:g7mnp3$v0h$1@aioe.org...

KJ wrote:

It doesn't, and your example is not one where the registers are not
used either since they are all addressable therefore they must all be
implemented. If this is what the OP had in mind when he said he had
'unused' registers then he is mistaken as well.

KJ


KJ,
You miss the point. How do I tell the synthesiser to ignore registers I'm
not going to use?

You "tell the synthesizer", by not providing any mechanism for the output of
the register to have any impact on any external I/O pins. That's always the
way things get optimized away.

In your example you had the following statement:
data_to_cpu <= registers(cpu_address);

Therefore, even if the CPU *will* never write to a certain set of registers,
you've written code in such a way that synthesis must implement the entire
set of 'registers' since the output data_to_cpu depends on all of them. By
providing a meachanism for register(3) (as an example) to affect an output
signal, you've forced it to implement register(3). One relatively simple
way around this is the following:

data_to_cpu <= registers(Masker(cpu_address));

where 'Masker' is some function that maps the entire input address space
down to the allowable set of addresses. As a simple exercise, if 'Masker'
always returned 0 then the synthesis tool will get rid of registers 1 on up,
leaving only register(0). It will work as well for any other arbitrary
'Masker' function.

As a side note, if 'register(3)' was not needed, one might be tempted to
have a statement like register(3) <= (others <= '0') or some such. While
the synthesis tool will use such a statement and produce less logic it is
still implementing register(3), register(3) just happens to always return a
0. When all is said and done, doing it this way by having a set of 'zero
registers' may produce less logic;it would depend on just how complicated
the 'Masker' function gets.

KJ

 

[Ben Jackson]

On 2008-08-12, Jason Hsu <jason_hsu@my-deja.com> wrote:

My Spartan 3 FPGA kit came with a cable that's supposed to plug into a
DB25 connector. However, the laptop computer I'm using for the kit
does not have any such jack on it.

What adapter can I use? My laptop has USB ports and a DB9 but no
DB25.

What you need is a printer port. A better solution is to buy a Xilinx
platform cable USB and give the parallel cable to someone who can use it.

(someone else pointed you at a db9-db25 adapter, probably for serial,
which is not useful to you)

--
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

 

[Pete Fraser]

"bart" <bart.borosky@latticesemi.com> wrote in message
news:3ce5a071-bb41-40db-947b-3b4e243d1ef1@y21g2000hsf.googlegroups.com...

Lattice is holding a webcast tomorrow, Wednesday, August 13th,
presenting our PCI Express IP offerings, various hardware evaluation
platforms, and the associated demos and reference designs for
evaluating PCI Express. The webcast is titled: "Evaluating and
Enhancing PCI Express Performance." The presenters will be Sid Mohanty
and Jamie Freed, from our strategic marketing and applications
engineering groups, respectively.

If you're interested, the event takes place live at 11am Pacific,
18:00 GMT. In addition, you will be able to view this webcast archive
on-demand, at your convenience, starting a few hours after the live
event takes place.

Is it really going to happen this time?
I signed up for it last time it it was announced,
but it was postponed. Half the system didn't realize this,
and much confusion ensued.

 

[Ben Jackson]

On 2008-08-15, MarkAren <markaren10@yahoo.com> wrote:

I still haven't figured out the time limited nature of the NIOS II
SOPC builder, could someone enlighten me please.

It's 60 minutes of runtime on the part without the JTAG cable
connected. If you keep the JTAG connection live then you can run
forever.

Also, what is the difference between the web edition and the fully
paid up version of Quartus II.

I think NIOS II is sold separately from the subscription Quartus II.
I think you buy NIOS one time and you have a perpetual license for that
version.

It's neat, and I've used the tethered version, but when I built a
Cyclone II project I just threw down a microcontroller rather than use
NIOS II. $500 will buy a lot of micros. I think their pricing
model is a mistake -- it keeps hobbiests from doing anything serious
with NIOS II and that keeps those same people from being able to
recommend it for "serious" designs, where the license fee is a drop in
the bucket compared to part sales.

--
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

 

[Ben Jackson]

On 2008-08-15, stewarma@gmail.com <stewarma@gmail.com> wrote:

Has anyone had any experience altering the porch/sync lengths and
pixel clock to keep 60Hz that will sync to an LCD monitor?

Most digital devices like LCDs seem fairly insensitive to the size of
the blanking intervals. I suspect there is at least SOME logic inside
which uses a few of those clocks for something, but 50 vs 60 lines of
blank are no big deal.

--
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

 

[KJ]

"andersod2" <thechrisanderson@gmail.com> wrote in message
news:91c3827f-cc64-485d-894d-7438de4673a4@b38g2000prf.googlegroups.com...

I just inserted an inferred ram module into my code, and all of a
sudden it takes forever to synthesize...I only inferred one
ramblock...is there anything I can do to get it down to a reasonable
time? I have a lot of warnings, but still...I went from a few seconds
to synth now taking minutes.....??

Most likely you're not quite following the template (although you think you
are) and what is getting synthesized has to get implemented in logic cells
rather than internal memory.

Another cause than cause logic instead of internal memory to be used that
I've seen is that even though my code exactly followed the template I had to
manually add an attribute to the read address signal to prevent the signal
from getting changed. Whatever it was doing optimized it into some form
that the synthesis tool thought it needed logic cells and couldn't use
internal memory. Since adding (or not adding) an attribute to a signal does
absolutely nothing to the function of the code, it was just something that
needed to be done. I opened a case with the tool supplier, not fixed yet,
possibly soon.

KJ

 

[Symon]

"tersono" <ethel.thefrog@ntlworld.com> wrote in message
news:equda41r55sn5pta3e58uikts03gku5lae@4ax.com...

A system with a 16-wide input bus, clocked (negative edge) into a
16-wide register.

(Actually a sub-set of a real system.)

The system clock input is balanced; it is converted to single ended
and fed to a clock buffer to clock the register.

The system outputs are

1/ the register output
2/ the single ended clock drive

I want to constrain the register output so that it changes less than
2.6ns after the fall of the clock output- a constraint between two
outputs.

Dear Ethel Frogface,

Use the IOB's DDR flipflops to output the clock. Use a '0' and a '1' on the
data inputs to the two DDR registers. Also, use the IOBs' flipflops for the
register you've made. Then the clock and the register outputs all change at
the same time.
HTH, Syms.

p.s. Philip F. claims to have invented this way of getting clocks out of
FPGAs. He always bleats on at me if I don't mention that! ;-)

 

[Symon]

"rickman" <gnuarm@gmail.com> wrote in message
news:d5d7b8d8-0dec-48c3-a26d-4cf644d35327@p25g2000hsf.googlegroups.com...

On Aug 16, 3:13 pm, "Symon" <symon_bre...@hotmail.com> wrote:
"tersono" <ethel.thef...@ntlworld.com> wrote in message

news:equda41r55sn5pta3e58uikts03gku5lae@4ax.com...


Dear Ethel Frogface,
Use the IOB's DDR flipflops to output the clock. Use a '0' and a '1' on
the
data inputs to the two DDR registers. Also, use the IOBs' flipflops for
the
register you've made. Then the clock and the register outputs all change
at
the same time.
HTH, Syms.

p.s. Philip F. claims to have invented this way of getting clocks out of
FPGAs. He always bleats on at me if I don't mention that! ;-)

Philip F's claims aside, is this really a useful way of propagating
the clock?

Yes.

With both the output clock and the registered data coming
from IOB FFs, won't there be a race condition?

No. Because...

I guess the receiving
chip can clock the data on the other edge of the clock,

Good idea! ;-)

but typically
when clocking on board, the data has a minimum hold time sufficient to
reliably clock the data into the receiving device. I don't think this
method will provide the required hold time.

OK, if you're set on using the 'same' edge instead of the 'other' one, then
if you're driving another FPGA, the inputs have special programmable delays
built in to give the appearance of zero hold time for the IOB input FFs. For
devices without zero hold time, read on below.

I have not used the DLLs before, but my impression was that they could
be used to clock the data out on a clock which is delay locked to the
actual board clock. The board clock output is feed back to an input
pin and run through the DLL. The DLL aligns it to provide the data
output at the time you require it. This should provide a sufficient
delay of the data so that a positive hold time can be provided.

Rick

Yep, that'll work provided the frequency of operation is within the DCM's
range. If the OP is worried about a 2.6ns delay, I guess the DCM will work
and I think the solution you suggest will work nicely. Even without
feedback, it's easy to use a DCM to generate a clock to drive the
DDR-clock-output-thingy suggested above to provide adjustable phase
difference between clock and data outputs.

HTH., Syms.