EDK : FSL macros defined by Xilinx are wrong

[info_]

Hi,

I would make a few of suggestions :

* use an enumeration and traditional "case state is when =>"
construct. This facilitates a lot of things, if only for the
synthesis tool to properly recognize your FSM, but also for
HSL simulation, readability, reliability, optimization etc...

* to output the state vector, use a simple decoder (which
will be probably eliminated by synthesis). And maybe you don't
want the one-hot vector vector to come out, but an binary
(more compact) version ?

* Single-process style is easier to write (imo) and not prone
to the usual errors in combinational processes.
(you're not the first and not the last to get caught)
You can even write Moore style in one process if
you don't want to move your actions in the transitions.

* Keep in mind that the synthesizer sometimes can guess
the "parallel case" and sometime can't.
This is likely your case (can't guess). It should have
trouble understanding that individual bit comparisons are
(probably) mutually exclusive.
So I'm afraid it would code the priority you've told him
implicitly to implement (last "if" does win).
I think this is inefficient synthesis-wise.

On my Website, you'll find many FSM examples, FWIW
http://www.alse-fr.com/English/ips.html

I never really liked the "textbook" two-processes style,
and I've seen lots of problems in code written this way...

But Text editors, FSM coding and VHDL vs Verilog are
almost religious issues ...

Bert

Preben Holm wrote:

Hi everyone,

I try to construct this statemachine as described in VHDL below:
(the machine is supposed to set the hold as soon as the trig-signal is
asserted (initialized only when all signals have been low for a
clock-cycle) and go low when both the read and holdoff signals have been
asserted for some time...

------------------------------------------
entity holdoffcontroller is
Port ( clk : in std_logic;
reset : in std_logic;
save : in std_logic;
trig : in std_logic;
read : in std_logic;
holdoff : in std_logic;
hold : out std_logic;
state : out std_logic_vector(4 downto 0));
end holdoffcontroller;

architecture Behavioral of holdoffcontroller is
constant stateStart : std_logic_vector(4 downto 0) := "00001";
constant stateWait : std_logic_vector(4 downto 0) := "00010";
constant stateTrigger : std_logic_vector(4 downto 0) := "00100";
constant stateHold : std_logic_vector(4 downto 0) := "01000";
constant stateRead : std_logic_vector(4 downto 0) := "10000";
begin

STATEMACHINE: block
signal current_state, next_state : std_logic_vector(4 downto 0)
:= stateStart;
begin
stateRegister : process(clk, reset)
begin
if reset = '1' then
current_state <= stateStart;
elsif rising_edge(clk) then
current_state <= next_state;
end if;
end process;


stateTransitions : process(current_state, holdoff, read, trig)
begin
-- stateStart
if current_state(0) = '1' then
hold <= '0';

if holdoff = '0' and read = '0' and trig = '0' then
next_state <= stateWait;
end if;
end if;
etc..

 

[info_]

Hi,

There is an LM70 (uWire / SPI) Temperature Sensor on our Tornado
board, and the VHDL code for the digital thermometer is free !

http://www.alse-fr.com/Tornado/Torn_Educ_us.pdf

We have also a reference design for the MaxII board with a different
temperature sensor (external transistor as sensor) : Max6627

This kind of interface is about 60 lines of (easy) code...
really simple.

I also wrote behavioral models for the Temperature sensors
so the design can be verified by simulation.

Best regards,

Bert

rgebru wrote:

Hi,

I'm thinkin go of designing a heating/cooling system with VHDL and
need to interface my Spartan 3 board to a real temp sensor. Does
anyone have an idea of how I can do this?

Thanks!!

 

[Preben]

info_ wrote:

Hi,

I would make a few of suggestions :

* use an enumeration and traditional "case state is when =>"
construct. This facilitates a lot of things, if only for the
synthesis tool to properly recognize your FSM, but also for
HSL simulation, readability, reliability, optimization etc...

I thought the one-hot approach was quite better for performance issues?

* to output the state vector, use a simple decoder (which
will be probably eliminated by synthesis). And maybe you don't
want the one-hot vector vector to come out, but an binary
(more compact) version ?

Well, you're just right about that, but for simulation purposes this
works just fine!
I actually only need three bit-outputs!

* Single-process style is easier to write (imo) and not prone
to the usual errors in combinational processes.
(you're not the first and not the last to get caught)
You can even write Moore style in one process if
you don't want to move your actions in the transitions.

Well, I tried doing this, but this gave me a lot of trouble so I took
the "VHDL made easy" book and did the "cooking book"-version of a
one-hot state machine design.

On my Website, you'll find many FSM examples, FWIW
http://www.alse-fr.com/English/ips.html

Thanks, i'll take a look!

I never really liked the "textbook" two-processes style,
and I've seen lots of problems in code written this way...

Maybe, Xilinx recommends this too, in their "templates".

 

[vax, 9000]

Preben Holm wrote:

Hi everyone,

I try to construct this statemachine as described in VHDL below:
(the machine is supposed to set the hold as soon as the trig-signal is
asserted (initialized only when all signals have been low for a
clock-cycle) and go low when both the read and holdoff signals have been
asserted for some time...

You made the typical mistake --- You didn't clock the inputs. Add one or
even two Flip-Flops to every input.

vax, 9000

 

What is this for? If you are a student and this is part of an
assignment I don't want to just give you the answer but that doesn't
mean I won't try to help you.

Are there any design requirements that need to be followed or met?

Style and presentation is very important with VHDL. WIth a programming
language like 'C' you can get away with creating compound and nested if
statements with different structures and with an optimizing compiler
end up with the same result.

Early when I was learning VHDL, I noticed that depending on how you
structure your code effects the circuit design. In VHDL the compiler
tries to implement designs it recognizes ie. state machines.

As, someone else pointed out, the way you went about implementing your
state machine isn't the expected way. Try implementng using case
structure instead of if control structure. Don't forget the differences
between case and if statements - if statements are evaluated sequential
and case states are evaluated parallel.

In VHDL as in C, if you have a large chunk of code and are having
trouble with it you should break it up into smaller chunks. Use block
and process structures to make your code smaller. It should make your
code easier to read and make the compilers job easier.

Derek

 

[Henrik Koksby Hansen]

I am not sure but is this got something to do with the DONE pin not
going high. I dont know abt platform studio but then with Project
navigator there is a setting which drives the done pin high that is if
the done pin in the circuit is not connected to a pullup resistor.
[...]

Yeah, but I can't seen to find any settings that does this. I am
pretty new to this.
Anyways, I powered off the board and soldered a 10kOhm resistor from
the DONE-pin to Vcc. And it actually worked after I powered it on
again and programmed it.

Hope this helps.
[...]

I hope so too. Only time will show if the pull-up resistor did the
trick. ;-)
[...]

Damn, it did not work. After some hours it went mad at me again.

Does anyone have any ideas on what to try out?


--
Henrik

 

[Peter Ryser]

The USB ports on the ML310 board are enabled when running the Linux demo
on the CompactFlash card. You can find information on how to build
your own Linux system by visiting the ML310 web page at
http://www.xilinx.com/ml310 and
http://www.xilinx.com/products/boards/ml310/current/index.html.

XAPP765 is also a good starting point for Embedded Linux on Virtex-II
Pro (and Virtex-4 FX), see http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf

Using the USB ports from standalone software is much more challenging as
you would have to write device drivers for the ALi south bridge as well
as code for the USB stack.

- Peter

more wrote:

Hello,

I am doing my thesis on Xilinx ML310 board. My target is to
realise the real-time image processing. First I have to find the port
where I can input the captured data. I am going to use the usb port on
MD1535D+ south bridge. To access this south bridge I need to access
the PCI bus since it is connected to the PCI. I have installed the
PCI v3.0 logicore but when I create a project, I can't find this PCI
v3.0 logicore to add into my project. Does anyone know how to access
this PCI v3.0 logicore?

Much appreciate for your kindly help!

 

[netpit]

Hello Vasanth,


About the malloc function, as you said "this is a known limitation",
can you tell me where this is written in the documentation ? (I knew
the IOCM is a 32-bit write only port for the Virtex II Pro but I
didn't read anything about relocation).

thanks again

Pierre

(XPS & ISE v6.02)

Vasanth Asokan <vasanth.asokan@xilinx.com> wrote in message news:<422E5CDA.6080206@xilinx.com>...
We compile newlib with -mrelocatable-lib option. This produces code that
contains pointers stored in the .text, instead of the .data. Since,
reading from the OCM on Virtex 2P is not supported, such code will not
work. malloc is one of our library routines that will fail. This is a
known limitation. Please move such library routines into other readable
memories. Then your code will work.

thanks,

 

[Brian Davis]

lecroy7...@chek.com wrote:

I am starting to suspect that the devices internal oscillator has a
problem. There is very little information about it. There appears
to be no way to detect it's failure.

If you ever are able to reproduce the problem at will, probably
the easiest way to check the health of the internal CCLK is to place
the part in master serial mode before initial powerup, so you can
observe the behavior of the CCLK output under the lockup-generating
conditions.

Unfortunately, my earlier suggestion (copied below) of trying
to switch the locked up part into master mode to observe CCLK
won't work if the internal CCLK isn't present: the 'deglitching'
samplers on PROG and RESET, needed to perform the switch, are
driven by that same internal CCLK source.

earlier, I wrote:

When you next induce this problem, here are some random thoughts
on additional sticks with which to poke at the stuck FPGA:

- longer ( >>6us ) reset and program pulses

- send more config data than needed and look for data to appear
on DOUT

- if possible, stop driving CCLK externally, switch the mode pins
on the stuck device to master serial, then reset and look for
CCLK coming out of the part

good luck,
Brian

 

If you ever are able to reproduce the problem at will, probably
the easiest way to check the health of the internal CCLK is to place
the part in master serial mode before initial powerup, so you can
observe the behavior of the CCLK output under the lockup-generating
conditions.

I don't know if the problem would show up in master mode. I don't want
to introduce any other variables into the system. I know it has this
problem with the current configuration.

I had tried to send out a few seconds of normal clock cycles once the
part was locked and was not able to get it to recover. But, again if
the device's internal clock was dead, then the device would not be able
to sample the Reset state.

After playing with various near field probe designs, I now have one
that appears to pick up the 1MHz internal clock. The probe hooks
directly to a 20db amplifier and off to the spectrum analyzer. I am
not working in a screen room right now but the signal does appear to be
from the FPGA and not a local radio station. It is very close (within
50KHz) to the 1MHz that is called out.

I have run three more days of tests and was not able to get the part
into the strange mode.

I am curious if Xilinx has had troubles with their internal oscillators
in the past. The newer parts are programmable where this part is not
(fixed clock rate). So some changes were made to the design.

I will post again once I can see if it is the clock or not.

 

[Preben Holm]

Sylvain Munaut wrote:

Well, they also screwed up the WebPack installer apparently ;(
A don't have any RHEL 3.0 handy to install and copy, I'll have to find
another
way.


Apparently just installing openmotif did the trick ( missing libXm.so.3 was
the problem )
I'm on gentoo btw

Well, I get an error about libcurl.so.2, I only have libcurl.so.3.0.0.
I tried creating an symbolic linking from libcurl.so.2 to
libcurl.so.3.0.0 but this doesn't work:

------
echelon tmp # ./WebPACK_71_fcfull_i.sh
Verifying archive integrity... All good.
Uncompressing Xilinx ISE WebPACK
Installer..............................................................................................................................................................................
/tmp/selfgz27591/platform/lin/bin/lin
Cannot register service: RPC: Unable to receive; errno = Connection refused
unable to register (registryProg, registryVers, tcp)
Wind/U Error (248): Failed to connect to the registry on server echelon
_X11TransSocketOpen: socket() failed for tcp
_X11TransSocketOpenCOTSClient: Unable to open socket for tcp
_X11TransOpen: transport open failed for tcp/echelon:0
Wind/U X-toolkit Error: wuDisplay: Can't open display


************ setup done! ***************

echelon tmp #
------


So, any idea what to do about this.


Thanks,
Preben (at the gentoo-box)

 

[John Williams]

Hi Henrik,

Henrik Koksby Hansen wrote:

I am not sure but is this got something to do with the DONE pin not
going high. I dont know abt platform studio but then with Project
navigator there is a setting which drives the done pin high that is if
the done pin in the circuit is not connected to a pullup resistor.

[...]
Damn, it did not work. After some hours it went mad at me again.

Does anyone have any ideas on what to try out?

I've seen similar strangeness on this board, maybe it's relevant. It
occurrs if I have the configuration mode jumpers set for Slave Serial
mode (e.g. for configuring from the PROM) but was actually configuring
via JTAG instead.

The fix for me was to ensure that the mode jumpers were in the exactly
correct place. So, for JTAG, I think that's Open closed open closed
(from left to right). Or, for PROM-configuration, all closed.

Hope this helps,

John

 

[Eric Smith]

Preben Holm <64bitNOnoSPAMno@mailme.dk> writes:

Well, I get an error about libcurl.so.2, I only have libcurl.so.3.0.0.
I tried creating an symbolic linking from libcurl.so.2 to
libcurl.so.3.0.0 but this doesn't work:

I wouldn't expect it to.

I used libcurl extracted from the curl RPM for Fedora Core 2, and it
worked fine.

I posted instructions for using 6.3i and 7.1i on Fedora Core 3, which
can be found on Google Groups:
http://groups-beta.google.com/group/comp.arch.fpga/msg/4b592cb14bad823f

I think most of the information would be generally applicable to other
distributions.

Eric

 

A second failure took place. I reset all of the ICs, disabled the
cards master clock and left all of the FPGAs in the unprogrammed state.
Looking around I was not able to tell if the 1MHz signal was present
or not. It is so far down in the noise floor that it is virtually
undetectable.

I decided to start looking at wider BWs. It appears that the internal
clock is not 1MHz, but much higher. Doing a sweep from 500KHz to 50MHz
and comparing the peaks, the IC that is in the strange state is missing
a peak at around 16-17MHz.

This signal is changes part to part which I would expect for a sloppy
oscillator.
Again, the data sheets do not mention this. I will try and call Xilinx
today and see if they can confirm that this is the internal clock.

 

To further verify that the 16MHz is the internal clock I tried to
change the temperature of the device to see how it effects the
frequency and indeed it does. Just what you would expect from an RC
design. I am very confident that the oscillator is the problem.

I did some searching and came across an app note form 1997 that talks
about the 1Mhz clock on the 3000.

"The nominal frequency of this oscillator is 1 MHz with a
max deviation of +25% to -10%. The clock frequency,
therefore, is between 1.25 MHz and 0.5 MHz. In the
XC4000 family, the 1-MHz clock is derived from an internal
8-MHz clock that also can be used as CCLK source."

I have provided Xilinx with the lot codes on these parts and I am
guessing that at some point the oscillator was changed to 16MHz on the
3000.

I am trying more tests now to try and get other oscillators to fail.

 

[Austin Lesea]

lecroy,

The oscillator itself is at a much higher frequency, and is divided down
to the number listed in the data sheet. At least, we still do it that
way, even today.

The accuracy of this oscillator would be from 1/2 to 2X the nominal (it
just isn't critical).

Since this part still had paper schematics (REALLY) it is far too old
for us to go look at its design.

Phil is on the right track.

This part did have a brownout issue (if the the voltage dropped just
right, for just the right amount of time, and came back up) that would
place it in a locked state that could not be recovered until the power
was cycled.

I solved this problem 15 years ago by using a Dallas Semi Power on Reset
part to reset the power supply if it detected a glitch.

The product was an optical multiplexer for then AT&T (and then Lucent).

We had sold more than 100K units in three years. I think you can still
buy them even today.

They are used in some applications that are actually critical, so they
went through an amazing battery of tests (for the audio radio channels
at all US and Canadian Airports, for example).

Austin


lecroy7200@chek.com wrote:

To further verify that the 16MHz is the internal clock I tried to
change the temperature of the device to see how it effects the
frequency and indeed it does. Just what you would expect from an RC
design. I am very confident that the oscillator is the problem.

I did some searching and came across an app note form 1997 that talks
about the 1Mhz clock on the 3000.

"The nominal frequency of this oscillator is 1 MHz with a
max deviation of +25% to -10%. The clock frequency,
therefore, is between 1.25 MHz and 0.5 MHz. In the
XC4000 family, the 1-MHz clock is derived from an internal
8-MHz clock that also can be used as CCLK source."

I have provided Xilinx with the lot codes on these parts and I am
guessing that at some point the oscillator was changed to 16MHz on the
3000.

I am trying more tests now to try and get other oscillators to fail.

 

[Henrik Koksby Hansen]

On Tue, 22 Mar 2005 09:40:07 +1000, John Williams
<jwilliams@itee.uq.edu.au> wrote:

Hi Henrik,
[...]

Hi John,

I am not sure but is this got something to do with the DONE pin not
going high. I dont know abt platform studio but then with Project
navigator there is a setting which drives the done pin high that is if
the done pin in the circuit is not connected to a pullup resistor.
[...]
Damn, it did not work. After some hours it went mad at me again.
[...]
I've seen similar strangeness on this board, maybe it's relevant. It
occurrs if I have the configuration mode jumpers set for Slave Serial
mode (e.g. for configuring from the PROM) but was actually configuring
via JTAG instead.

The fix for me was to ensure that the mode jumpers were in the exactly
correct place. So, for JTAG, I think that's Open closed open closed
(from left to right). Or, for PROM-configuration, all closed.
[...]

All jumpers was actually closed. I tried to set the jumpers as
described. By the way, it tells the same jumber positions in the
manual for the board on p. 22. Unfortunatly it did not work. I
additionally tried disabling the PROM by JP28, but that makes no
difference either.

I'll just power cycle the board a few times, and un- and replug until
it suddenly works. But it would be nice to get it working every time.
I will talk to a Memec guy on tuesday - if I have no solution by then
I will try and ask him. And, if he has a solution, I will post it in
here.

Please let me know if you have any further ideas - I appreciate any
help I get.


--
Henrik

 

[Jim Granville]

lecroy7200@chek.com wrote:

A second failure took place. I reset all of the ICs, disabled the
cards master clock and left all of the FPGAs in the unprogrammed state.
Looking around I was not able to tell if the 1MHz signal was present
or not. It is so far down in the noise floor that it is virtually
undetectable.

I decided to start looking at wider BWs. It appears that the internal
clock is not 1MHz, but much higher. Doing a sweep from 500KHz to 50MHz
and comparing the peaks, the IC that is in the strange state is missing
a peak at around 16-17MHz.

This signal is changes part to part which I would expect for a sloppy
oscillator.
Again, the data sheets do not mention this. I will try and call Xilinx
today and see if they can confirm that this is the internal clock.

That freq makes more sense than 1MHz for the buried osc, as 1MHz is
relatively slow, so needs more specialised die area - in the old process
of the 3000, a ring osc will give 16-17MHz region. Dividers are simple.

If you need additional confirmation it is inside the FPGA, you could
give the chip a squirt of freeze - ring osc's are temp dependant.

They are likely to gate the loader osc, to save power, so this
may only confirm you have exited the first power-up load state,
but are unable to get back into load state.
-jg

 

[Jim Granville]

Austin Lesea wrote:

lecroy,
Phil is on the right track.

This part did have a brownout issue (if the the voltage dropped just
right, for just the right amount of time, and came back up) that would
place it in a locked state that could not be recovered until the power
was cycled.

Do you recall how low the Vcc had to cycle, in order to correctly recover ?

I solved this problem 15 years ago by using a Dallas Semi Power on Reset
part to reset the power supply if it detected a glitch.

Sounds just like my power removal wdog....
How did you 'detect a glitch' - was that simply via Vcc lowering, or
did that get an "I'm OK" signal from the FPGA ?

I have wondered why more regulator chips do not offer this type of
'wide hysteresis' in their operation.

-jg

 

[Austin Lesea]

Jim,

See below,

Austin

Jim Granville wrote:

Austin Lesea wrote:

lecroy,
Phil is on the right track.

This part did have a brownout issue (if the the voltage dropped just
right, for just the right amount of time, and came back up) that would
place it in a locked state that could not be recovered until the power
was cycled.


Do you recall how low the Vcc had to cycle, in order to correctly recover ?

As I recall, it had to go below 150 mV to 300 mV to recover.

I solved this problem 15 years ago by using a Dallas Semi Power on
Reset part to reset the power supply if it detected a glitch.


Sounds just like my power removal wdog....
How did you 'detect a glitch' - was that simply via Vcc lowering, or
did that get an "I'm OK" signal from the FPGA ?

The POR IC had a settable threshold with an external resistive divider.
It responding very quickly. I set it to the voltage range I knew I
never wanted to be in. I think that was anything below 2.5V. For a 5V
supply, I figured many bad things would happen if I went below 2.5V.

I have wondered why more regulator chips do not offer this type of
'wide hysteresis' in their operation.

-jg

The problem is how do you tell? A band gap reference takes a lot of
area, and is hard to be accurate in the really deep sub micron
tecnologies. So if you can't measure more accurately that +/-5%, why
bother?