EDK : FSL macros defined by Xilinx are wrong

[Fredrik]

The DBC1C12 board is metion in this post is avalible at Elfa in Sweden,
not super cheep but afordable.
Regards
Fredrik

 

[Enno Luebbers]

As far as I've tried it, just enabling virtex-4 support in the MPD file
doesn't help. The hwicap core uses the ICAP_VIRTEX2 component, which
obviously is not supported on the Virtex-4. I didn't try changing the
hwicap source to use the new ICAP_VIRTEX4 - that might work, since it
still supports the 8 bit SelectIO interface.

Regards
-Enno

 

[Falk Salewski]

"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag
news:4448ed30$0$18265$9b4e6d93@newsread2.arcor-online.net...

Falk Salewski schrieb:
I am doing some research on the reliability of microcontrollers software
in
comparison to hardware description languages for PLDs (CPLD/FPGA).

Another interesting point is whether there are general benefits of one
hardware regarding reliability, e.g. in an automotive environment.

This all depends on the type of errors you are talking about. To get an
overall estimate will be really difficult.

E.g. in automotives a big issue are real time constraint violations when
many things happen at once. You can easily specify the timing of most
hardware implemented algorithms with a granularity of nanoseconds
because there is real concurrency in the implementation. For uC it is
hard to get below tens of microseconds.

Also, error detection and correction on ALUs, busses and memory is just
not available for commercial uC, while you can easily implement it for
your FPGA circuit. In theory a uC using all these techniques would be
more reliable, but if you can not buy it....
(BTW: I talked to Bosch about that topic, and apparently the volume of
their orders is not big enough to have Motorola design such a uC for
them.)

Formal model checking and property checking are becoming mainstream for
hardware development but are hardly ever used for software development.

These are all factors in favor of FPGAs that are often not considered,
but I am sure that you come up with many reasons why uCs are more
reliable. (Less transistors for example)

Kolja Sulimma

Thanks for your reply! I am also of the opinion that applications realizing
hard real-time parallel functionality are easier to verify on a device
allowing real parallelism.
Possible integration of error detection and correction functionalities in
FPGAs are also a big plus, in my opinion.
Finally it seems that the aspect MCU vs. FPGA regarding reliability is,
again, application dependent.

Falk Salewski

 

[Karl]

Here are the details. The DSP kit should also become 2C70, but the
webpage is not updated yet...

http://altera.com/products/devkits/altera/kit-video-cyclone2.html

Cheers, Karl.

 

[Tommy Thorn]

Karl wrote:

Here are the details. The DSP kit should also become 2C70, but the
webpage is not updated yet...

http://altera.com/products/devkits/altera/kit-video-cyclone2.html

Very cool, the very first kit with the 2C70 It looks like I'll have
to roll my own extender card to get network, mass storage, and kbd/mouse.

Thanks Karl.

Tommy

 

[David]

Yes, these are the great disadvantages of the UC-II design. The work flow is different like the XPS work flow, and the modification of the design must be do with ISE, but that is simply another way of work. You can choose: ˇ XPS work flow: very compatible, with a great quantity of memory, with the PLB and OPB buses but with a great consumption of resources. ˇ UC II designs: You have a lot of resources avalaible and the 32 Kb of memory are cache, the fastest possible, but the work flow it's a low level work flow but there exists options to expand the design.

I have introduced some modifications to the TEMAC UCII design. I will inform about the results

Regards

 

[David]

Hi Marco

What about the MPMC 2 component? Do you know if the GSRD has been updated?

Regards

 

[Rene Tschaggelar]

Falk Salewski wrote:

I am doing some research on the reliability of microcontrollers software in
comparison to hardware description languages for PLDs (CPLD/FPGA).

Another interesting point is whether there are general benefits of one
hardware regarding reliability, e.g. in an automotive environment.



I read about certification problems if a SRAM based FPGA is programmed every
system start and that Flash or Fuse based systems are preferable. I also
read that CPLDs (Flash) in general are more robust than FPGAs.

Can you confirm/confute this?

What are the allowed failure modes ? All of them ?
That includes alpha particles, fast protons, thermal
cycles, vibrations, supply and signal issues, electric
and magnetic fields, the lot.
Plus how failure prof is the design. How can it handle
unexpected values. While in some points 90nm technology
is more sensitive, it is not that an acre of 2N3055
doing the same would be more reliable.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

 

[Marco T.]

"David" <david.quinones@imagsa.com> wrote in message
news:ee98d76.4@webx.sUN8CHnE...

Hi Marco

What about the MPMC 2 component? Do you know if the GSRD has been updated?

Regards

Hi David,
I'm still waiting that GSRD team will port lwip to plb_temac. It will be
available into EDK 8.2 release (not 8.1.2).

Marco

 

[Colin Paul Gloster]

Kolja Sulimma wrote in
news:4448ed30$0$18265$9b4e6d93@newsread2.arcor-online.net :

"[..]

Formal model checking and property checking are becoming mainstream for
hardware development but are hardly ever used for software development.

[..]"

There is a difference between being mainstream and being available. Formal
methods have existed for a long time for software. Just as one should not
be willing to take a software developer opposed to formal methods, one
should not be willing to take a hardware developer who has only acquired
exposure to formal methods because of a trend instead of actively
appreciating the need for formal methods.

On Thu, 27 Apr 2006, Falk Salewski wrote:

"[..] I am also of the opinion that applications realizing
hard real-time parallel functionality are easier to verify on a device
allowing real parallelism.
[..]"

Of course implementing parallelism with real parallelism is easier, but
verifying something whether it is implemented with true parallelism or
interleaved sequential code should take the same effort no matter the
implementation: check whether the inputs and the outputs match.

 

[Falk Salewski]

"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> schrieb im Newsbeitrag
news:20060503210430.A70973@docenti.ing.unipi.it...

Of course implementing parallelism with real parallelism is easier, but
verifying something whether it is implemented with true parallelism or
interleaved sequential code should take the same effort no matter the
implementation: check whether the inputs and the outputs match.

I still believe that verifying parallel structures on a PLD is easier than
on a CPU. Imagine a program, that has to handle certain communication
interfaces (CAN, RS232,..) and has to measure some real-time signals at the
same time. In case of a PLD these modules could be checked separately, since
no dependencies according to a single CPU are present. In case of a CPU
based system this dependencies are crucial (in real-time systems) and a lot
of test efford is spend to examine these.

 

[David Q.]

Hi boys, good news!!

The GSRD team will be release a new version of the GSRD using the MPMC2 at the end of May.

I'm waiting that impatiently

Best regards

 

[David Q.]

Hi boys, good news!!

The GSRD team will be release a new version of the GSRD using the MPMC2 at the end of May.

I'm waiting that impatiently

Best regards

 

[Symon]

"Kolja Sulimma" <news@sulimma.de> wrote in message
news:4459d02d$0$4501$9b4e6d93@newsread2.arcor-online.net...

IMHO it is embarrassing that a 2006 compiler cannot synthesize

if rising_edge(clk) and enable='1' then...

Hi Kolja,

Just out of curiosity, which compiler are you talking about? XST? Synplify
seems fine, I do get a "Feedback mux created for signal xxxxx" warning, but
the output doesn't have this mux. Thanks.
Cheers, Syms.

 

[Kolja Sulimma]

Symon schrieb:

"Kolja Sulimma" <news@sulimma.de> wrote in message
news:4459d02d$0$4501$9b4e6d93@newsread2.arcor-online.net...

IMHO it is embarrassing that a 2006 compiler cannot synthesize

if rising_edge(clk) and enable='1' then...


Hi Kolja,
Just out of curiosity, which compiler are you talking about? XST? Synplify
seems fine, I do get a "Feedback mux created for signal xxxxx" warning, but
the output doesn't have this mux. Thanks.
Cheers, Syms.

I never used synplify, but it is plausible that it has a more modern
view on what should be synthesizable and what should not, as the company
was started at a time where people allready complained about such
limitations.

I discovered limitations like these in the last couple of years in
Synopsys FPGA Compiler as well as Design Compiler, in Magma DAs Blast
RTL and in XST.

IMHO the worst limitation was a version ov Blast RTL that restricted
generics to be of type integer. My code used to turn on feature with
boolean values. No it uses integers...

Kolja Sulimma

 

[Mike Treseler]

Kolja Sulimma wrote:

IMHO it is embarrassing that a 2006 compiler cannot synthesize
if rising_edge(clk) and enable='1' then...

I don't know of a recent release that causes such embarrassment.
The example below works fine on Quartus.
The downside to this template is that it clock enables
everything in the process -- too restrictive for me.

-- Mike Treseler

___________________________
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity clk_en is
generic (vec_len : positive := 8);
port (
clk : in std_ulogic;
reset : in std_ulogic;
enable : in std_ulogic;
q : out std_logic_vector(vec_len-1 downto 0)
);
end entity clk_en;

architecture synth of clk_en is
begin
clk_en : process(reset, clk) is
subtype vec_t is unsigned(vec_len-1 downto 0);
constant vec_init : vec_t := "10110011";
variable reg_v : vec_t;
begin -- process template
if reset = '1' then
init_regs : reg_v := vec_init;
elsif rising_edge(clk) and enable = '1' then --<
update_regs : reg_v := rotate_left(reg_v, 1);
end if;
update_ports : q <= std_logic_vector(reg_v);
end process clk_en;
end architecture synth;

 

[Symon]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:4bv0puF12s3kqU1@individual.net...

The downside to this template is that it clock enables
everything in the process -- too restrictive for me.

Hi Mike,

I try to make sure every process (and, of course, every entity) has an
enable. Even if the enable is set to '1' in the code, it makes it a lot
easier to reuse in future designs with faster clocks.
Sadly, I don't always remember to do this. :-(
Cheers, Syms.
p.s. Jan, sorry for wandering off topic!

 

[Andrew Lohbihler]

"Zara" <yozara@terra.es> wrote in message
news:aid9321jos46c9kqo56ispelb6cdliho9o@4ax.com...

On Wed, 5 Apr 2006 05:25:59 -0700, ahakan <> wrote:

Thanks for your response, but I am using Parallel Cable IV, so I guess the
problem is not due to the parallel cable (I tried the Platform Cable USB
as well).


I have the same problem from time to time with PCIV (not tried with
other cables) and XC3S400.

Sometimes it is just a momentary problem, you muts just try again and
it programs OK. Sometimes it is plain stupidity of (I suppose) the
FPGA, switch power off and on again, it usually works.

Best regards,

Zara

I have always had this problem using the parallel cable IV as above. Even
with my Virtex 4 board the problem was even more apparent likely because the
bit files are so much larger. My strategy was to switch the board off and on
and restart iMPACT and possibly even regenerate the bit file. I think that
the parallel stream occasionally creates errors and this error happens. I
always program the SPROM and do my unit testing from there rather than
program every time with the JTAG port.

Hope that helps,
Andrew

 

I've been running into a similar problem recently. For me, ISE would
freeze after the prompt that asked if I wanted to unlocked the project
file, or would just never load (and eat up 99% of the CPU).

It seems to work if I replace the .ise file with a backed-up .ise file,
then actually delete the .lock file before starting up ISE. From
browsing Xilinx support it looks like there may be issues with ISE
corrupting the .ise file on a crash. I'd recommend keeping your own
backup (NOT the automatic backup) of the .ise file. Wonder why could
they didn't just keep the project file a simple ASCII file like the old
..npl?

I agree that ISE stability has gone downhill. Altera had a lot of
customers defect after their first buggy Quartus tools--Xilinx should
take note.

Brian Walkington

 

[Jim Wu]

You can assign MGT pins in ADEPT. Here is the web site:

http://home.comcast.net/~jimwu88/tools/adept/

HTH,
Jim