EDK : FSL macros defined by Xilinx are wrong

[Roger]

Thanks for your comments. It doesn't sound like there's an obvious answer to
this one. I thought someone from Xilinx might post a comment.

Rog.

"Roger" <enquiries@rwconcepts.co.uk> wrote in message
news:TAoJf.39670$K42.16607@newsfe7-win.ntli.net...

I have a design with an Aurora RocketIO core and in the UCF file I've
added the following lines:

INST Inst_rio0_top/Inst_rio0/lane_0_phase_align_i/phase_align_flops_r*
AREA_GROUP="PHASE_ALIGN_0_GRP";

# Place RIO0 lane_0_mgt_i at location X0Y1
INST Inst_rio0_top/Inst_rio0/lane_0_mgt_i LOC=GT_X0Y1;

AREA_GROUP "PHASE_ALIGN_0_GRP" RANGE=SLICE_X14Y152:SLICE_X15Y153;

When I use PACE to modify a pin assignment or something equally trivial
and save the UCF, the AREA_GROUP "PHASE_ ..........;" line has
disappeared. Although the Aurora core does still seem to work, I thought
that the placement of the phase alignment FFs was important and was
explicitly indicated for good reason. Can anyone tell me what's going on
here please? Even if there's some setting somewhere that's telling the PAR
to ignore this type of constraint, why does it disappear? Is it something
to do with the fact that except for the pin assignments, all the UCF file
has been added textually i.e. not via PACE or the Constraints Editor?

TIA,

Rog.

 

[JustJohn]

Sylvain Munaut wrote:

John_H wrote:
I couldn't find my notes quickly so I'll just ask the question:

Are you certain that the dob_i and doa_i signals from the dual-port CLB
SelectRAM - DPO and SPO, respectively - are on the correct pins (I1/I0) for
the MUXF5? You could just try swapping I1/I0 for a quick check to see if
the orientation is inverted from what you expect.
No I'm not sure it's correct in the version I gave (I think so though),
but I did try different swapping of the pins for the MUXF5 and MUXF6,
none worked.

Sylvain, try again (hope you haven't started writing a lot of scripts
yet). The code below packs correctly into two slices without the
location constraint and init attributes (even using 6.3.03i), I'd be
surprised if adding them makes it fail to pack. I think John_H gave you
good advice. It did take me an hour to work out correctly... now I can
get to today's Sudoku puzzle...

Regards,
Just John


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_arith.ALL;
-- Uncomment the following lines to use the declarations that are
-- provided for instantiating Xilinx primitive components.
library UNISIM;
use UNISIM.VComponents.all;

entity Sylvains_poser is
Port (
clk : in std_logic;
we : in std_logic;
di : in std_logic;
addr_a : in std_logic_vector( 3 downto 0 );
addr_b : in std_logic_vector( 3 downto 0 );
imm : in std_logic_vector( 3 downto 0 );
sel_imm : in std_logic_vector( 1 downto 0 );
sel_ab : in std_logic;
sel_rm : in std_logic;
dout : out std_logic;
dout_a : out std_logic;
dout_b : out std_logic
);
end Sylvains_poser;

architecture Behavioral of Sylvains_poser is
signal doa : std_logic;
signal dob : std_logic;
signal mux_ram : std_logic;
signal mux_imm : std_logic;
signal out_sel : std_logic_vector( 1 downto 0 );
signal dp_16x1 : std_logic_vector( 0 to 15 ) := x"1234";
begin
-- process( clk )
-- begin
-- if RISING_EDGE( clk ) then
-- if we = '1' then
-- dp_16x1( conv_integer( UNSIGNED( addr_b ))) <= di;
-- end if; end if;
-- end process;
-- doa <= dp_16x1( conv_integer( UNSIGNED( addr_a )));
-- dob <= dp_16x1( conv_integer( UNSIGNED( addr_b )));
dout_a <= doa;
dout_b <= dob;
memcell_I: RAM16X1D
port map (
DPO => doa,
SPO => dob,
A0 => addr_b(0),
A1 => addr_b(1),
A2 => addr_b(2),
A3 => addr_b(3),
D => di,
DPRA0 => addr_a(0),
DPRA1 => addr_a(1),
DPRA2 => addr_a(2),
DPRA3 => addr_a(3),
WCLK => clk,
WE => we
);
with sel_imm select mux_imm <=
imm(0) when "00",
imm(1) when "01",
imm(2) when "10",
imm(3) when "11",
'-' when others;
RAM_Mux : MUXF5
port map (
O => mux_ram,
I0 => dob,
I1 => doa,
S => sel_ab);
Mux_RM : MUXF6
port map (
O => dout,
I0 => mux_ram,
I1 => mux_imm,
S => sel_rm);
end Behavioral;

 

[Sylvain Munaut]

JustJohn wrote:

Sylvain Munaut wrote:

John_H wrote:

I couldn't find my notes quickly so I'll just ask the question:

Are you certain that the dob_i and doa_i signals from the dual-port CLB
SelectRAM - DPO and SPO, respectively - are on the correct pins (I1/I0) for
the MUXF5? You could just try swapping I1/I0 for a quick check to see if
the orientation is inverted from what you expect.

No I'm not sure it's correct in the version I gave (I think so though),
but I did try different swapping of the pins for the MUXF5 and MUXF6,
none worked.


Sylvain, try again (hope you haven't started writing a lot of scripts
yet). The code below packs correctly into two slices without the
location constraint and init attributes (even using 6.3.03i), I'd be
surprised if adding them makes it fail to pack. I think John_H gave you
good advice. It did take me an hour to work out correctly... now I can
get to today's Sudoku puzzle...

Regards,
Just John

... code snipped ...

THANK YOU !

Damn you're right, I must have missed that particular mux config, I
probably tried one combination two times ...

I already made a hardmacro test but I like the HDL better especially
since you apparently can't "configure" a hardmacro, I would have had to
do 16 differents hardmacro cells ...

Well, the tools did get it after all, it was me who failed

Sylvain

 

[Paul Hartke]

No, the PowerPC405 caches in the current Xilinx FPGAs are not cache
coherent and so do not support SMP.

Paul

Osnet wrote:

Does anyone know if MontaVista Linux or other distributions support SMP
in Virtex-II Pro and Virtex-4? Thanks.

 

[Simon Peacock]

ahh but you are out of luck. Whichever disti first quotes you on a part is
the best price anyone else can give. Call it a conspiracy but that's the
disti way.

Your best bet is to just ask a disti. If you are ordering small quantities,
sometimes you can get a good price by piggybacking your order on someone
else's order. For instance, I saw on Toms Hardware that the latest video
card uses a 3S400. Chances are they are buying hundreds of thousand parts,
so their disti could give a good price by ordering one extra tray every now
and again for you. We did the same to get a 3S1000 at the same price as a
2S200E.

If your product is selling a million a month or year, then the price you
will get has absolutely no reflection on reality. it comes down to how
cheaply and efficiently Xilinx or Altera or Lattice can produce the FPGA for
you... and they will produce it for you too. In that volume you just about
get to name your own price.

Simon

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:1140318351.652961.327590@g47g2000cwa.googlegroups.com...

Xilinx XC3S1000-4FG456I
Altera EP2C20F484I8
Lattice ECP2-12E-5F484I

I find that the differences between the parts are not so great that I
want to exclude any of them. I would like to get an idea of how the
pricing compares. I am looking for other than the list prices which
tell me more about the distributor's markup than it does the price I
can otherwise get. I figure asking here might be quicker than waiting
for a price quote.

 

[Sylvain Munaut]

Osnet wrote:
Does anyone know if MontaVista Linux or other distributions support SMP
in Virtex-II Pro and Virtex-4? Thanks.

Paul Hartke wrote:

No, the PowerPC405 caches in the current Xilinx FPGAs are not cache
coherent and so do not support SMP.

I don't really get the relation between the two facts ... The OS could
enforce coherency in software, by forcing a cache flush during task
switching I think ...

Sylvain

 

[Rainer Buchty]

In article <43f849af$0$2132$ba620e4c@news.skynet.be>,
Sylvain Munaut <com.246tNt@tnt> writes:
|> Paul Hartke wrote:
|> > No, the PowerPC405 caches in the current Xilinx FPGAs are not cache
|> > coherent and so do not support SMP.
|>
|> I don't really get the relation between the two facts ... The OS could
|> enforce coherency in software, by forcing a cache flush during task
|> switching I think ...

The idea of having caches also means that they are transparent so that you
do *not* need any sort of special treatment by the programmer or operating
system.

Besides, flushing with task switching wouldn't help as memory write accesses
will occur independently from task switches, so your OS would need to keep
track of memory accesses of all CPUs in your SMP system to block reads to
"dirty" addresses until they have been written back by the "dirtying" CPU,
i.e. the OS would have to establish a cache coherency protocol entirely in
software and without typical hardware assist as required for cache coherency
protocols in hardware like MESI.

Rainer

 

[Sylvain Munaut]

Rainer Buchty wrote:

In article <43f849af$0$2132$ba620e4c@news.skynet.be>,
Sylvain Munaut <com.246tNt@tnt> writes:
|> Paul Hartke wrote:
|> > No, the PowerPC405 caches in the current Xilinx FPGAs are not cache
|> > coherent and so do not support SMP.
|
|> I don't really get the relation between the two facts ... The OS could
|> enforce coherency in software, by forcing a cache flush during task
|> switching I think ...

The idea of having caches also means that they are transparent so that you
do *not* need any sort of special treatment by the programmer or operating
system.

Well, there are quite a few CPU where you need to enfore coherency by
hand when using DMA for example (there is even a flag for not coherent
cache cpu in the kernel) ...

Besides, flushing with task switching wouldn't help as memory write accesses
will occur independently from task switches, so your OS would need to keep
track of memory accesses of all CPUs in your SMP system to block reads to
"dirty" addresses until they have been written back by the "dirtying" CPU,
i.e. the OS would have to establish a cache coherency protocol entirely in
software and without typical hardware assist as required for cache coherency
protocols in hardware like MESI.

I don't get that sorry ... (note that you may be right, i'm just trying
to understand here)
I'm not that familiar with SMP but here is how it goes for me :
Processes have two kind of writable memory zones, either private to the
process or shared between several processes.

* For independent address space, since the task will run only on a CPU
at a time, cache problem only occurs when a task is stopped on one cpu
and launched on the other. So just after stopping the task, the cpu
should flush it's cache so that if the task is launched on the other
cpu, the other has access to up-to-date memory.
* For shared zone between processes, there is no problem either. While
the two processes are running simultaneously, no problem can occur
because the processes must handle the synchronisation themselves even on
cache coherent system (by semaphore, or flag in memory, whatever ...).
And when only one is running, the situation is similar to the
independent zones.


Sylvain

 

[Sylvain Munaut]

Jordi wrote:

Hi,
I'm new in fpgas.I've been researching about vga timings for a few
days, but all information I've found it's confusing. I will try to
explain what I've learn:

HS,VS signals are active low. HS tells the monitor to begin a new line,
VS tells the monitor to begin a new frame. Before activate HS ,monitor
must be in blanking mode (front porch),before draw another line monitor
must leave blanking mode (back porch). The same for VS. There is an
active time to draw all line pixels.

I'm correct?

HS & VS are not necessarly active low, it depends of the mode. Note that
all recent monitor I tried absolutly didn't care about polarity and
locked what ever I used ...

You have :
* Front porch : Sync signal is not active, video signal is at blanking
level
* Sync : Sync signal is active, video signal is at blanking level
* Back porch : Sync signal is not active, video signal is at blanking level
* Active video : Sync signal is not active, video signal is whatever
you need to display

and that's for both h & v sync.

I don't understand timing.
For example if back porch takes 4us and active time takes 25 us in a
640x480 screen

Is the monitor expecting this timings? I mean , if I stay 8 useconds in
back porch will the monitor wait for me? , or will it begin to draw the
line after 4us?

Is the monitor reading RGB data every (25us/640)?

The monitors try to "lock" onto the input signal ... depending on the
monitor a particular signal might be recognized or not ... The only way
to ensure it's gonna be recognized by all monitor is to use a "standard"
timing. If it's just for experimentation, just try ... it might just
work ...


Sylvain

 

[Jan Panteltje]

On a sunny day (19 Feb 2006 06:02:13 -0800) it happened "Jordi"
<a80x86@hotmail.com> wrote in
<1140357733.500121.71180@g47g2000cwa.googlegroups.com>:

Hi,
I'm new in fpgas.I've been researching about vga timings for a few
days, but all information I've found it's confusing. I will try to
explain what I've learn:

HS,VS signals are active low. HS tells the monitor to begin a new line,
VS tells the monitor to begin a new frame. Before activate HS ,monitor
must be in blanking mode (front porch),before draw another line monitor
must leave blanking mode (back porch). The same for VS. There is an
active time to draw all line pixels.

I'm correct?
I don't understand timing.
For example if back porch takes 4us and active time takes 25 us in a
640x480 screen

Is the monitor expecting this timings? I mean , if I stay 8 useconds in
back porch will the monitor wait for me? , or will it begin to draw the
line after 4us?
The horizontal timebase in the monitor will be triggered by the neg sync edge,

and that is when it starts scanning.
If you make backporch (blanking) longer, you will just get a vertical black bar on
the screen.

Think of the 'monitor' as just 2 oscillators, one for H and one for V.
These are triggered by H and V, and in fact H uses PLL and likely V too.
So withing allowable syc range for a monitor you can change H and V frequency.
So look at the back and front porch as just a percentage of the time a scanline takes.
In fact these blanking areas are to prevent you to see non-linear effects in the scanning

Is the monitor reading RGB data every (25us/640)?
When the spot (still talking analog monitor) moves from left to right in that 25 uS

its intensity is set by the voltage at the input.
It has limited bandwidth though, and a limited number of pixels corresponding
to a limited number of holes in the shadowmask, so you cannot feed it 800MHz and
expect more detail ;-)

 

[Mike Harrison]

On Sun, 19 Feb 2006 19:01:52 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (19 Feb 2006 06:02:13 -0800) it happened "Jordi"
a80x86@hotmail.com> wrote in
1140357733.500121.71180@g47g2000cwa.googlegroups.com>:

Hi,
I'm new in fpgas.I've been researching about vga timings for a few
days, but all information I've found it's confusing. I will try to
explain what I've learn:

HS,VS signals are active low. HS tells the monitor to begin a new line,
VS tells the monitor to begin a new frame. Before activate HS ,monitor
must be in blanking mode (front porch),before draw another line monitor
must leave blanking mode (back porch). The same for VS. There is an
active time to draw all line pixels.

I'm correct?
I don't understand timing.
For example if back porch takes 4us and active time takes 25 us in a
640x480 screen

Is the monitor expecting this timings? I mean , if I stay 8 useconds in
back porch will the monitor wait for me? , or will it begin to draw the
line after 4us?
The horizontal timebase in the monitor will be triggered by the neg sync edge,
and that is when it starts scanning.
If you make backporch (blanking) longer, you will just get a vertical black bar on
the screen.

Think of the 'monitor' as just 2 oscillators, one for H and one for V.
These are triggered by H and V, and in fact H uses PLL and likely V too.
So withing allowable syc range for a monitor you can change H and V frequency.
So look at the back and front porch as just a percentage of the time a scanline takes.
In fact these blanking areas are to prevent you to see non-linear effects in the scanning
Is the monitor reading RGB data every (25us/640)?
When the spot (still talking analog monitor) moves from left to right in that 25 uS
its intensity is set by the voltage at the input.
It has limited bandwidth though, and a limited number of pixels corresponding
to a limited number of holes in the shadowmask, so you cannot feed it 800MHz and
expect more detail ;-)

Something else to note - make sure that the video signal is properly blanked throughout the porch
and sync periods. Failing to do this can confuse the auto-adjust process on LCD monitors.

 

[Sylvain Munaut]

Mike Harrison wrote:

On Sun, 19 Feb 2006 19:01:52 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:


On a sunny day (19 Feb 2006 06:02:13 -0800) it happened "Jordi"
a80x86@hotmail.com> wrote in
1140357733.500121.71180@g47g2000cwa.googlegroups.com>:


Hi,
I'm new in fpgas.I've been researching about vga timings for a few
days, but all information I've found it's confusing. I will try to
explain what I've learn:

HS,VS signals are active low. HS tells the monitor to begin a new line,
VS tells the monitor to begin a new frame. Before activate HS ,monitor
must be in blanking mode (front porch),before draw another line monitor
must leave blanking mode (back porch). The same for VS. There is an
active time to draw all line pixels.

I'm correct?
I don't understand timing.
For example if back porch takes 4us and active time takes 25 us in a
640x480 screen

Is the monitor expecting this timings? I mean , if I stay 8 useconds in
back porch will the monitor wait for me? , or will it begin to draw the
line after 4us?

The horizontal timebase in the monitor will be triggered by the neg sync edge,
and that is when it starts scanning.
If you make backporch (blanking) longer, you will just get a vertical black bar on
the screen.

Think of the 'monitor' as just 2 oscillators, one for H and one for V.
These are triggered by H and V, and in fact H uses PLL and likely V too.
So withing allowable syc range for a monitor you can change H and V frequency.
So look at the back and front porch as just a percentage of the time a scanline takes.
In fact these blanking areas are to prevent you to see non-linear effects in the scanning

Is the monitor reading RGB data every (25us/640)?

When the spot (still talking analog monitor) moves from left to right in that 25 uS
its intensity is set by the voltage at the input.
It has limited bandwidth though, and a limited number of pixels corresponding
to a limited number of holes in the shadowmask, so you cannot feed it 800MHz and
expect more detail ;-)


Something else to note - make sure that the video signal is properly blanked throughout the porch
and sync periods. Failing to do this can confuse the auto-adjust process on LCD monitors.

Also, make sure you use "strong" drivers for the lines that goes
directly to the VGA monitor. I had a "oscillating" image on a lcd
monitor because my hsync & vsync line were 12mA SLOW drivers. Using 24ma
and FAST made the problem go away ...

Sylvain

 

[Hal Murray]

It doesnt meat the spec thats what im saying, this area is one of the major
problems with PCI and 3.3v systems such as your FPGA, as i said in our
development boards we make sure the rest of the PCI bus meets there
specification and then make sure the trace lengths of the clock signal
either side of the bus switch is longer than your worst case by 0.5inches or
greater.
This works for our systems and we have seen no problems, making the trace
longer ensures you meet the set up and hold times for the rest of the bus.

Making the clock track longer gives you better setup but reduces your
hold time on data getting written to your chip.

For reads from your chip (or DMA writes), you have to make sure
your clock to out timings allow for two types of extra delay.
First is getting through the bus switch. Second is the extra
delay because your clock is late because it is going through
the bus switch on the way in.

--
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.

 

[Antti]

No, you cant use FPGA alone, if you want DVI-LVDS take a TI DVI
receiver, chances are that you can connect the display to it almost
directly there was an project with free PCB design for this kind of
converter but unfortunatly I cant find the link any more.

optionally you may use FPGA *after* the DVI receiver if needed for some
reason.

Antti

 

[Antti]

no

an Analog VGA to digital is almost even more complex, there is almost
only chip available for purchasing (ADI sells only for 20K+ year
customer) the available chip is Averlogic AL875, but unfortunatly it is
missing internal PLL so you need additionally ICS1523 or similar - I
have the Averlogic ADC but not the PLL so cant test it - (I have a
pending design inquiry for VGA to usb conversion)

the TI chip is actually pretty simple, the board that I was referring
too had pretty much only the TI chip and connectors on the board

Antti

 

[Falk Brunner]

Marko schrieb:

Traditionally, firmware was defined as software that resided in ROM.
So, my question is, what do you call FPGA code? Is "firmware"
appropriate?

Why not?

Regards
Falk

 

[Marko]

On Mon, 20 Feb 2006 19:47:16 +0100, Falk Brunner <Falk.Brunner@gmx.de>
wrote:

Marko schrieb:
Traditionally, firmware was defined as software that resided in ROM.
So, my question is, what do you call FPGA code? Is "firmware"
appropriate?

Why not?

Are you answering my question with a question?

Seriously, I just want to know what other people call it. It seems
incorrect to refer to FPGA code by the same name used for ROMable S/W.
At my previous job, we just called it "FPGA Code". At my new job,
it's called "firmware".

 

[Jordi]

Hi,
thanks to all for the answers !!! (and sorry for my bad english
)

I think I'm begining to understand how it works.

If the monitor uses PLL then the HSync frecuency determines how fast
the monitor moves the beam.So if I increase the HSync frecuency the
active time is shorter(and the back and front porch) but I can draw
more lines per second so I can have better resolutions. I don't
understand how resolution control works. The monitor has a fixed number
of pixels(Let's supose a 1024x768 monitor). If I ouput 640x480 images
and the monitor must draw 1024 pixels per line and 768 lines, then some
pixels will be repeated. Isn't it?

Thanks in advance,

Jordi

 

[Falk Brunner]

Marko schrieb:

Why not?

Are you answering my question with a question?
Seriously, I just want to know what other people call it. It seems
incorrect to refer to FPGA code by the same name used for ROMable S/W.
At my previous job, we just called it "FPGA Code". At my new job,
it's called "firmware".

I don't see the big problem there. There are hundreds of synonyms
floating around. "FPGA-Code" is more or less the same as "Firmware".
There is no official definition or standard, also no defacto standard.
So call it whatever you like it as long as it's in sync with the people
you are talking to.

Regards
Falk

 

[m]

On Mon, 20 Feb 2006 21:01:52 +0100, Falk Brunner <Falk.Brunner@gmx.de>
wrote:

Julian Kain schrieb:
The difference is execution versus synthesis. Firmware is indeed
embedded and dedicated code, but the code is executed. FPGA code is
written in a _description_ language, is then interpreted, synthesized,
and ultimately produces hardware.

VHDL may "produce" hardware when doing ASIC design.

So what do you call a gate array or structured asic ? What does VHDL
do when it generates files for one of these processes ? (for the
uninitiated gate-arrays or structured asics in general have all their
base layers produced already and several metals are used configure the
manufactured general purpose gates to what you want and provide the
connectivity).
By the same token when you take a bit file generated for an FPGA and
use it to produce a hard-copy device (a structured asic specifically
generated for a certain FPGA family) does the VHDL suddenly realize
that it has produced hardware ? What does this say for laser trim or
metal only ECO ?
Also is an Intel or AMD processor really hardware as they have
micro-code which can be downloaded by BIOS which can be used to fix
quite a bit of "issues" with the processor.

In an FPGA not a single bit is "produced", all is fixed.

So the function of each LUT and how they are all connected are fixed
and the VHDL doesn't produce anything ? What does it do then ? If in
my standard cell design, I have memory based FSMs the function of
which can be changed by updating the contents of such, does my asic
become software ? What about external pins which can change the
behaviour of combinational FSMs ?

I think the issue is a lot less clean-cut then is suggested here.