Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 125200

Article: 125200
Subject: Re: xil_printf and %u specifier
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 17 Oct 2007 21:01:57 -0000
Links: << >>  << T >>  << A >>
On 17 Okt., 19:46, Philip Potter <p...@see.sig.invalid> wrote:
> Hello all,
>
> I'm using EDK 9.1.02i to develop an application for the Xilinx
> University Program Virtex-II Pro board.
>
> I created a bare MicroBlaze project and ran the following program on it:
>
> #include <stdio.h>
>
> int main(void) {
>      unsigned int i = 10;
>      xil_printf("Signed: %d Unsigned: %u\r\n",(int) i, i);
>      return 0;
>
> }
>
> The output (over the serial port) was this:
>
> Signed: 10 Unsigned:
>
> Apparently xil_printf() ignores the %u format specifier. What's going on?
>
> --
> Philip Potter pgp <at> doc.ic.ac.uk

xil_printf has limited support for the formats, check it out what is
supported

Antti



Article: 125201
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround
From: Dave <dhschetz@gmail.com>
Date: Wed, 17 Oct 2007 14:15:02 -0700
Links: << >>  << T >>  << A >>
Antti,

Could you fix the typo on the line with the do64(62 downto 0)
assignment - there's an array length mismatch. Also, what is the
definition of do64 - std_logic_vector(63 downto 0)?

On Oct 17, 4:44 pm, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi ho
>
> here is code
>
> process (m_sck) begin
>         if (m_sck'event and m_sck=3D'1') then
>                 do64(62 downto 0) <=3D do64(62 downto 0) & M_DI;
>         end if;
> end process;
> LEDS <=3D do64s(63 downto 60);
>
> M_DI, M_SCK are driven by external MCU SPI interface.
> the MCU send either
> 0x90 00 00 00 00 00 00 00
> or
> 0x00 00 00 00 00 00 00 00
>
> symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> when the FPGA is full, there will blink all off, then 1-1-0-1
> repeating same pattern, not randomness
>
> changing maxfanout in synplify will change the erratic behaviour but I
> have not managed to get the shift register ever work in case where
> FPGA is really full.
>
> SPI clock is 4MHz (or lower doesn seem to make any difference)
>
> this time I am giving up, that is not trying to force the shift
> register to work, but find solution that works
>
> the problem only occourcs on Actel FPGA, and yes yes it works in
> s=EDmulation it works in xilinx FPGA, etc..
>
> Antti
> who this time really doesnt know the solution :(



Article: 125202
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 17 Oct 2007 21:19:39 -0000
Links: << >>  << T >>  << A >>
On 17 Okt., 23:15, Dave <dhsch...@gmail.com> wrote:
> Antti,
>
> Could you fix the typo on the line with the do64(62 downto 0)
> assignment - there's an array length mismatch. Also, what is the
> definition of do64 - std_logic_vector(63 downto 0)?
>
> On Oct 17, 4:44 pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi ho
>
> > here is code
>
> > process (m_sck) begin
> >         if (m_sck'event and m_sck=3D'1') then
> >                 do64(62 downto 0) <=3D do64(62 downto 0) & M_DI;
> >         end if;
> > end process;
> > LEDS <=3D do64s(63 downto 60);
>
> > M_DI, M_SCK are driven by external MCU SPI interface.
> > the MCU send either
> > 0x90 00 00 00 00 00 00 00
> > or
> > 0x00 00 00 00 00 00 00 00
>
> > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > when the FPGA is full, there will blink all off, then 1-1-0-1
> > repeating same pattern, not randomness
>
> > changing maxfanout in synplify will change the erratic behaviour but I
> > have not managed to get the shift register ever work in case where
> > FPGA is really full.
>
> > SPI clock is 4MHz (or lower doesn seem to make any difference)
>
> > this time I am giving up, that is not trying to force the shift
> > register to work, but find solution that works
>
> > the problem only occourcs on Actel FPGA, and yes yes it works in
> > s=EDmulation it works in xilinx FPGA, etc..
>
> > Antti
> > who this time really doesnt know the solution :(- Zitierten Text ausble=
nden -
>
> - Zitierten Text anzeigen -

sorry my eyes see double(almost, just hurt), i cleaned the code and
madetypo

signal do64 : std_logic_vector(63 downto 0) ;


process (m_sck) begin
         if (m_sck'event and m_sck=3D'1') then
                 do64(63 downto 0) <=3D do64(62 downto 0) & M_DI;
         end if;
end process;
LEDS <=3D do64(63 downto 60);







Article: 125203
Subject: Re: FPGA to FPGA Bus
From: Gabor <gabor@alacron.com>
Date: Wed, 17 Oct 2007 14:21:35 -0700
Links: << >>  << T >>  << A >>
On Oct 16, 2:35 pm, Eric Smith <e...@brouhaha.com> wrote:
> "Amontec, Larry" <laurent.ga...@ANTI-SPAMamontec.com> writes:
> > Is whishbone bus a multi-master bus ?
>
> Not in the conventional sense.  It's not well-suited for an off-chip
> interconnect.


You may want to check out the "J" mode bus on the local bus side of
various PLX bridges (9000 series and 8311).  This is fairly simple
compared to PCI and came from a standard microprocessor bus.

The PLX part datasheets have lots of timing diagrams showing bus
operation under all sorts of conditions.

Cheers,
Gabor


Article: 125204
Subject: Re: difference between XC5VLX50-1FFG676C and XC5VLX50-1FFG676CES
From: austin <austin@xilinx.com>
Date: Wed, 17 Oct 2007 14:27:34 -0700
Links: << >>  << T >>  << A >>
Michel,

ES = "engineering sample"

This is what we call parts BEFORE they are qualified for production.

In some cases, ES parts are completely identical to the final
production, and in other cases, they are not identical (they have known
bugs or problems we call "errata").

CES = "commercial grade engineering sample" (it has a speed grade)

Go look for V5 errata at:

http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?iLanguageID=1&category=-1212267&sGlobalNavPick=&sSecondaryNavPick=

to find the exact differences.

If you have questions about any of these errata, please contact your
distributor or Xilinx FAE.

We sell ES parts to customers early in order to give them a head-start
on their design and debugging (over their competition).

The risk of purchasing an ES part, is they may have bugs (known, as
detailed in the errata, or as of yet unknown, as all testing may not be
complete nor all test programs in place).  If the parts have bugs, there
is no warranty (they are non-returnable, non-refundable).  The normal
warranties do not apply to an ES part.

As an example, ES parts are never accepted for a "RMA" (returned
merchandise authorization) or for F/A (failure analysis).

It is recommended that ES never be used for production product.  If used
for production product, the purchaser must accept all of the risks, as
Xilinx has stated these parts are not intended nor recommended for
production product.

This is pretty standard practice in the industry, and is not unique to
FPGA technology either.

Austin

Article: 125205
Subject: Re: difference between XC5VLX50-1FFG676C and XC5VLX50-1FFG676CES
From: ghelbig@lycos.com
Date: Wed, 17 Oct 2007 21:27:46 -0000
Links: << >>  << T >>  << A >>
On Oct 17, 1:52 pm, michel.ta...@gmail.com wrote:
> Hi alls,
>
> I've a question which seems stupid, but I don't find answer anywhere..
> ( maybe I don't search correctly )
> What is the difference between XC5VLX50-1FFG676C and
> XC5VLX50-1FFG676CES ? I don't understand what does 'ES' mean at the
> end of the FPGA reference ..
>
> So, please, if anyone knows..
>
> Thanks by advance,
>
> best regards, Michel.

Look here: <http://www.xilinx.com/xlnx/xweb/
xil_publications_display.jsp?category=Errata/FPGA+Device+Families/
Virtex-5>

The link was found by doing a search for XC5VLX50-1FFG676CES on the
Xilinx web site.

G.


Article: 125206
Subject: Re: Reason for LUT1_L buffer insertion in Synplify EDIFs?
From: Neil Steiner <neil.steiner@vt.edu>
Date: Wed, 17 Oct 2007 17:28:03 -0400
Links: << >>  << T >>  << A >>
John_H wrote:
> Neil Steiner wrote:
>> When generating EDIF from Synplify, I frequently notice buffers 
>> (LUT1_L primitives with INIT property of 2) inserted in the circuit.  
>> Does anybody know why the tool is doing this and/or whether it can be 
>> disabled?
>>
>> [snipped]

Thanks for the response, John.

> While the INIT property of 2 leaves me a little confused (I would expect 
> 1 or 0 for a LUT1) ... 

Let's see if I can get this right.  A 1-input LUT is a 2-bit RAM.  In 
the case of a buffer, the 10 (binary) value gets replicated as 
1010101010101010 and inverted to 0101010101010101.  The MSB of that word 
is addressed when all inputs are zero, so {A1,A2,A3,A4}={0,0,0,0} 
returns 0.  More generally, {A1,A2,A3,A4}={0,x,x,x} returns 0, and 
{A1,A2,A3,A4}={1,x,x,x} returns 1.  It's this weird LUT math thing ... ;)

> ... the presence of "glorified pass-through" elements are often
> required to drive carry chains properly.

... and I will concede that there are carry chain elements on nearby 
nets ...

> Do you know the structure of the slice very well?  

I do.  That's not to say I can't be making a mistake, but I'm quite 
familiar with the FPGA Editor view, as well as the rules about what can 
and cannot be mixed and matched within a slice.  (Not all of the actual 
rules are apparent from the FPGA Editor view.)  From a slice component 
perspective, I have yet to find a situation where these buffers were 
strictly required.  Or stated differently, even though I trim the 
buffers, the implementations still work properly in hardware.

> I have a graphic of the slice internals pinned to my cubicle wall to
> refer to anytime I see something odd in my Synplify HDL Analyst
> technology view, usually because my coding comes up with something
> that doesn't fit the way I expect with the tool most often doing the
> right thing for the RTL I've presented. I usually just need to tweak
> my thinking and the code to get the "clean" results I thought I'd get
> the first round.

That does make sense, but I'm seeing behavior like this even in the 
trivially simple case of a 32-bit counter:

     process(clk)
     begin
         if rising_edge(clk) then
             if reset = '1' then
                 reg <= (others => '0');
             else
                 reg <= reg + 1;
             end if;		
         end if;
     end process;

I can't really tweak that code without instantiating a carry chain 
structurally.  So I remain puzzled about the behavior, though I do 
appreciate your comments.  Apart from research purposes (my case), I 
assume that the Xilinx tools are the only consumer of Synplify EDIF 
(when targeting Xilinx parts), so I half wonder whether there's some 
kind of dependency thing going on with the two tools, possibly for 
legacy reasons ...

Article: 125207
Subject: Re: High level FPGA work flow: available tool?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 17 Oct 2007 14:36:55 -0700
Links: << >>  << T >>  << A >>
Andy wrote:

> While it is possible to raise the level of abstraction using single
> processes, variables, functions, etc., the description must still be
> explicitly about what happens in each and every clock cycle.

That is the downside, but that is
also the ticket to easy synthesis.

If I can't get n:=n+1; done in
one clock cycle, I have to break
up the variables and declare
a counter or enumeration
to update and case.

But I expect that an embedded C programmer
who has written an interrupt routine would get it
for control logic and simple math.
It might even placate Maroc's boss :)

I agree that complicated DSP requires some
sort of algorithm generator like matlab or Catapult
(and thanks for the catapult tutorial by the way)

> Even some
> simple cases of retiming can allow one to describe an operation that
> will take place over a specific number of clock cycles, but you have
> little or no control over the resulting division of the circuit across
> clock cycles.

I don't see that as a downside as long as
the simulation matches at the ports.

> ... Catapult is clearly a datapath tool; it does not handle
> arbitrary control logic very well.

And this is where plain-old vhdl is more than good enough.

      -- Mike Treseler


Article: 125208
Subject: Re: High level FPGA work flow: available tool?
From: pivvosh <pivvosh@tlen.pl>
Date: Wed, 17 Oct 2007 23:40:55 +0200
Links: << >>  << T >>  << A >>
hans64@ht-lab.com pisze:
> On Oct 17, 11:40 am, Maroc <md2...@libero.it> wrote:
>> Thanks.
>>
>> In Xcell Journal the proposed tool are "function-specific" or oriented
>> to Hardware Acceleration.
>>
>> I'm looking for a work flow to develop generel purpose FPGA function,
>> starting from high level description.
>>
>> For example I'd like to start from "C-model" or "MATLAB model" or "?!?
>> model" and by using efficent compiler obtain a synthesizable RTL code.
>>
>> I don't know this world (I always used VHDL or block diagram)...plese
>> be patient!
>>
>> thanks, thanks
> 
> There are a number of tools that operate in the ESL/synthesis space,
> however, you need a serious EDA budget to get any of these tools. In
> addition to this these tools are not general purpose and they normally
> operate well in a particular niche area (e.g. DSP/datapath). You
> already mentioned Catapult that can synthesize C/C++ to HDL (Verilog/
> VHDL), other tools like Catalytic can convert M-Code to C, tools like
> SystemCrafters/ForteDS/BlueSpec/Agility/etc allow you to go from
> SystemC to HDL but as I mentioned, these tools are not cheap, work in
> a niche area and require specialist knowledge to drive them well.
> 
> Hans
> www.ht-lab.com
> 

Maybe AutoPilot tool is cheaper ?
It converts high-level C/C++/SystemC code to RTL.

see http://www.autoesl.com/product.html

P.

Article: 125209
Subject: Re: Reason for LUT1_L buffer insertion in Synplify EDIFs?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 17 Oct 2007 17:44:10 -0400
Links: << >>  << T >>  << A >>

Synplify has changed how they do this several times over the years.  I'm 
pretty sure they insert the buffers if the logic preceding the carry 
chain would cause the carry chain to be broken by the optimization 
without the lut buffers.  They had a problem with earlier releases where 
a constant on one of the bit inputs to the carry chain would cause the 
carry chain to be broken into two segments, which made for some pretty 
ugly mappings.  The LUT1 mapping though does occasionally cause 
problems, notably when there is an instantiated or keep-buffered lut 
(done to strongly hint to the synthesis that you want it done in a 
particular way) followed by an inferred carry chain.

Article: 125210
Subject: Re: Altera devices connecting to DDR memory.
From: pgw <"SwietyMikolaj["@]poczta.onet.pl>
Date: Thu, 18 Oct 2007 00:01:34 +0200
Links: << >>  << T >>  << A >>
parekh.sh@gmail.com wrote:

> Typically, each 8 bits of DQ and corresponding DM bit are grouped
> together with an associated DQS bit.  The idea is that individual pins
> in this group will see similar skews.  Therefore, the DQS to data/dm
> relationship will not suffer at the memory or fpga.  If you are going
> to be running at the max rated operating frequency it would be
> important to keep the group as suggested.

Thanks for response.

-- 
pgw

Article: 125211
Subject: Re: xil_printf and %u specifier
From: Philip Potter <pgp@see.sig.invalid>
Date: Thu, 18 Oct 2007 00:28:19 +0100
Links: << >>  << T >>  << A >>
Antti wrote:
> On 17 Okt., 19:46, Philip Potter <p...@see.sig.invalid> wrote:
>> Apparently xil_printf() ignores the %u format specifier. What's going on?
>>
> 
> xil_printf has limited support for the formats, check it out what is
> supported

Hi antti,

Thanks for your answer. Where would I find such documentation? I've 
checked in the OS and libraries reference manual, but that only has a 
brief description and doesn't mention unsigned.

-- 
Philip Potter pgp <at> doc.ic.ac.uk

Article: 125212
Subject: Re: difference between XC5VLX50-1FFG676C and XC5VLX50-1FFG676CES
From: Eric Smith <eric@brouhaha.com>
Date: Wed, 17 Oct 2007 17:32:33 -0700
Links: << >>  << T >>  << A >>
austin wrote:
> As an example, ES parts are never accepted for a "RMA" (returned
> merchandise authorization)

Makes perfect sense.

> or for F/A (failure analysis).

You guys don't want to determine why ES parts fail?  That seems
really strange.

Article: 125213
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 18 Oct 2007 11:12:17 +1000
Links: << >>  << T >>  << A >>
Antti wrote:

> signal do64 : std_logic_vector(63 downto 0) ;
> process (m_sck) begin
>          if (m_sck'event and m_sck='1') then
>                  do64(63 downto 0) <= do64(62 downto 0) & M_DI;
>          end if;
> end process;
> LEDS <= do64(63 downto 60);

What a maintenance nightmare!!

process (m_sck)
  variable do64 : std_logic_vector(63 downto 0);
begin
  if m_sck'event and m_sck = '1' then
    do64 := do64(do64'left-1 downto 0) & M_DI;
  end if;
  LEDS <= do64(do64'left downto do64'left-3);
end process;

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 125214
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 18 Oct 2007 11:19:13 +1000
Links: << >>  << T >>  << A >>
Antti wrote:

> M_DI, M_SCK are driven by external MCU SPI interface.

Sounds to me like you've got skew between M_DI & M_SCK at the
shift-register clk, data inputs.

Your evidence suggests that M_DI lags M_SCK... can you super-sample the
inputs (they're only 4MHz) and adjust for the skew internally?

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 125215
Subject: Re: Reason for LUT1_L buffer insertion in Synplify EDIFs?
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 18 Oct 2007 05:19:24 GMT
Links: << >>  << T >>  << A >>
Neil Steiner wrote:
<snip>>
> That does make sense, but I'm seeing behavior like this even in the 
> trivially simple case of a 32-bit counter:
> 
>     process(clk)
>     begin
>         if rising_edge(clk) then
>             if reset = '1' then
>                 reg <= (others => '0');
>             else
>                 reg <= reg + 1;
>             end if;       
>         end if;
>     end process;
> 
> I can't really tweak that code without instantiating a carry chain 
> structurally.  So I remain puzzled about the behavior, though I do 
> appreciate your comments.  Apart from research purposes (my case), I 
> assume that the Xilinx tools are the only consumer of Synplify EDIF 
> (when targeting Xilinx parts), so I half wonder whether there's some 
> kind of dependency thing going on with the two tools, possibly for 
> legacy reasons ...

In Verilog, I'd rearrange the equation to always add one to a value 
that's dependent on the synchronous reset such as

always @(posedge clk)
   reg <= (reset ? -1 : reg) + 1;

but since VHDL doesn't have a conditional operator (?) I'd do the 
assignment outside the synchronous process, still adding one whether the 
reset is asserted or not, the init coming through the "other" addend of -1.

It's not so much that Synplify can't optimize logic extremely well, it's 
that it doesn't do math with foresight.  It's often a matter of 
rearranging the math to make the adders come out as "simple" adders.

It could be that if both sides of your if/else added the invert of 
reset, the synthesizer would recognize the structure and "do the right 
thing."  Expecting the synthesizer to do rudimentary algebra is 
something I'd like to see, but perhaps asking a smidgen too much.


Oh - and I understand the LUT1 INIT of 2 now.  I know this stuff, it 
just gets hazy when I've been away from INITs for a few months.  Any 
recent manual INITs I've done with binary equations from constants 
I0=aaaa, I1=cccc, I2=f0f0, and I3=ff00 with LUT4s.

- John_H

Article: 125216
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 18 Oct 2007 05:50:45 -0000
Links: << >>  << T >>  << A >>
On 18 Okt., 03:19, Mark McDougall <ma...@vl.com.au> wrote:
> Antti wrote:
> > M_DI, M_SCK are driven by external MCU SPI interface.
>
> Sounds to me like you've got skew between M_DI & M_SCK at the
> shift-register clk, data inputs.
>
> Your evidence suggests that M_DI lags M_SCK... can you super-sample the
> inputs (they're only 4MHz) and adjust for the skew internally?
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266

Mark,

I was evidencing the complete design to fail to operate in the target
FPGA
same design was known to work in simulation and in other FPGA family
as well.

the 4MHz SPI signals are "near perfect" there is the clock alignment
on the inputs is defenetly perfect.
I a sampling at correct clock edge as well. The SPI clock shows little
overshoot but thats all

now what made the puzzle harder, at initial testing when i wasnt 100%
of the SPI modes, etc, it
looked like the 64 bit register would hold correct value, 1 bit
shifted, as if the SPI master sends
always 1 extra clock. to correct this and aligne data I did take added
flip flop. stupid, but it seemed
to work. and yes i had to add the 65th clock pulse in simulation
testbench too. After that it looked like ok.
but the complete design still failed to fully operate.

now, the upper 4 bits of the register are used to "change mode"
depending on the value, the mode change
did not work. as FPGA has been is 80-98% full, so I used LEDs and
UJTAG for debugging. connected
"mode detect" to LED, wrong, then connected mode_detect to UIREG6 -
this is where the problem described
in quiz1 appeared!!

before going totally nuts, I finally removed the rest of the logic
around the shift the register, and the it
id start to work and shift properly.

playing around with maxfanout and global treshold in Synplify does
seem to have influence how wrong
the shift register shifts, but I had to time to go on forever trying
to find a fanout-treshold values that would
make all work.

during testing with 4LED on shiftregister in big design, when it
failed the same wrong (1-1-0-1 instead 1-0-0-1)
patter was observable in all supply range where the board did stay
operational, to my surprise the PCB
FPGA+AVR MCU did work down to 1.7V and down to 1.7V the shift-led did
show 1101 so the huge supply
variation did make a difference. I assume the AVR generated signal did
change a lot in amplitude, slew, overshoot, etc at lower supply, also
AVR clock lowered maybe 2 times, but that all did not make any
difference.
so whatever causes the bad shift its very stable in given P&R run.

as I said, I have no plausible explanation or cure.
I did give up, and optimized the 64 bit register (it was holding a
blowfish key challenge) away - and problem has disappeared as well.

but it leaves an un-easy feeling, if the FPGA was working wrong
because of unexplained reason, the same or similar reason could cause
new trouble somewhere else too.

the big desing has 1 parallell, 2 SPI slave, 2 SPI master, 1 sd card
master interface, 6 global and 1 quadrant clock are used

there is 50MHz free running clock, yes I tried to oversample and
moreover glitch filter the SPI clock for the failing register, first
trial did not give any result or improvement, and I did give up on
that direction, the direct clocking looked as working better

Antti


Article: 125217
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround
From: neilla@pipstechnology.co.uk
Date: Thu, 18 Oct 2007 00:37:03 -0700
Links: << >>  << T >>  << A >>
On 17 Oct, 21:44, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi ho
>
> here is code
>
> process (m_sck) begin
>         if (m_sck'event and m_sck=3D'1') then
>                 do64(62 downto 0) <=3D do64(62 downto 0) & M_DI;
>         end if;
> end process;
> LEDS <=3D do64s(63 downto 60);
>
> M_DI, M_SCK are driven by external MCU SPI interface.
> the MCU send either
> 0x90 00 00 00 00 00 00 00
> or
> 0x00 00 00 00 00 00 00 00
>
> symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> when the FPGA is full, there will blink all off, then 1-1-0-1
> repeating same pattern, not randomness
>
> changing maxfanout in synplify will change the erratic behaviour but I
> have not managed to get the shift register ever work in case where
> FPGA is really full.
>
> SPI clock is 4MHz (or lower doesn seem to make any difference)
>
> this time I am giving up, that is not trying to force the shift
> register to work, but find solution that works
>
> the problem only occourcs on Actel FPGA, and yes yes it works in
> s=EDmulation it works in xilinx FPGA, etc..
>
> Antti
> who this time really doesnt know the solution :(

So is m_sck actually using global routing, or has it been routed
normally?

I've seen similar problems when clocks have been routed using local
nets.  I would suggest forcing m_sck to use a global net, or since
your using Actel you could force it on to one of the local global
spines.  I can't remember how to do it, but I know there is an app
note saying what constraints are needed.

Neill.


Article: 125218
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Thu, 18 Oct 2007 10:37:35 +0300
Links: << >>  << T >>  << A >>
Antti wrote:

> but it leaves an un-easy feeling, if the FPGA was working wrong
> because of unexplained reason, the same or similar reason could cause
> new trouble somewhere else too.

Did you check the final results Synplify generated (technology mapping)
and if that result was sane. At least Synplify 8.8 was unusable due
to many bugs. S 8.6.2 and 8.9 seem to be better in terms of creating
working chips.

--Kim

Article: 125219
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 18 Oct 2007 07:49:42 -0000
Links: << >>  << T >>  << A >>
On 18 Okt., 09:37, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> Antti wrote:
> > but it leaves an un-easy feeling, if the FPGA was working wrong
> > because of unexplained reason, the same or similar reason could cause
> > new trouble somewhere else too.
>
> Did you check the final results Synplify generated (technology mapping)
> and if that result was sane. At least Synplify 8.8 was unusable due
> to many bugs. S 8.6.2 and 8.9 seem to be better in terms of creating
> working chips.
>
> --Kim

the failing desing was made with S 8.8A1 and was not tested with other
version of synthesis tools

after my quiz1 issue, that looked like tool error or faulty FPGA, I
was not to belive that another problem so close the first one is
related to tools making a mess, so I was very hard trying to find
problem in my design.

I have made backup of the "known failing with 8.8" design, when i have
time, i will retest it with 8.6.2

I did look actel technology view, and did not see anything totally
wrong at quick look, but i also did not fully look it over as the
signals are hard to follow

and thanks a zillion - the suggestion that "8.8 was unusable" it is
golden already, it gives hope that the problem is solvable

Antti


Article: 125220
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 18 Oct 2007 07:54:08 -0000
Links: << >>  << T >>  << A >>
On 18 Okt., 09:37, nei...@pipstechnology.co.uk wrote:
> On 17 Oct, 21:44, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
>
>
> > Hi ho
>
> > here is code
>
> > process (m_sck) begin
> >         if (m_sck'event and m_sck=3D'1') then
> >                 do64(62 downto 0) <=3D do64(62 downto 0) & M_DI;
> >         end if;
> > end process;
> > LEDS <=3D do64s(63 downto 60);
>
> > M_DI, M_SCK are driven by external MCU SPI interface.
> > the MCU send either
> > 0x90 00 00 00 00 00 00 00
> > or
> > 0x00 00 00 00 00 00 00 00
>
> > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > when the FPGA is full, there will blink all off, then 1-1-0-1
> > repeating same pattern, not randomness
>
> > changing maxfanout in synplify will change the erratic behaviour but I
> > have not managed to get the shift register ever work in case where
> > FPGA is really full.
>
> > SPI clock is 4MHz (or lower doesn seem to make any difference)
>
> > this time I am giving up, that is not trying to force the shift
> > register to work, but find solution that works
>
> > the problem only occourcs on Actel FPGA, and yes yes it works in
> > s=EDmulation it works in xilinx FPGA, etc..
>
> > Antti
> > who this time really doesnt know the solution :(
>
> So is m_sck actually using global routing, or has it been routed
> normally?
>
> I've seen similar problems when clocks have been routed using local
> nets.  I would suggest forcing m_sck to use a global net, or since
> your using Actel you could force it on to one of the local global
> spines.  I can't remember how to do it, but I know there is an app
> note saying what constraints are needed.
>
> Neill.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

with defaul maxfanout of 12 synplify insert some 5 buffer in the M_SCK
path
global clocks are all used, because of routing constraints some set-
reset nets need to be driven by global nets otherise designer will use
2 cells for 1 flip flop, the FPGA is very full so I used the global
nets first to optimize for smallest FPGA resource useage.

but - global or not, a 64 bit shift register clocked at 4MHz should
work in ANY modern FPGA no matter what.
there can not be any setup or hold violation. and the same erratic
shift was also happening at even lower clock, below 2MHz.

and yes I play some more with the global nets, they seem to be a key
in Actel technology.

Antti


Article: 125221
Subject: systemc thread processes are called with the same thread in windows
From: CMOS <manusha@millenniumit.com>
Date: Thu, 18 Oct 2007 01:45:06 -0700
Links: << >>  << T >>  << A >>
i observed that all processes registered with SC_THREAD macro are
called with the same thread. Is this correct?
In my module im having a infinite loop inside the process which reads
from a port attached to sc_signal_in_if, which does not wait but
return immediately. see below : this is the testbench of a UART, which
waits for the start bit. when thread arrives here, it never exit. so
my other processes are never called once the thread enters this
process, because it uses the same thread for all of them.

void data_receive()
	{
		cout << __FUNCTION__ << " : " << GetCurrentThreadId() << endl;
		wait(1, SC_NS);
		while(true)
		{
			if(serial_data_in_port->read() == 0) //start bit
			{
				// othet statements

			}
		}
	}


Article: 125222
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 18 Oct 2007 22:00:49 +1300
Links: << >>  << T >>  << A >>
Antti wrote:
> but - global or not, a 64 bit shift register clocked at 4MHz should
> work in ANY modern FPGA no matter what.
> there can not be any setup or hold violation. and the same erratic
> shift was also happening at even lower clock, below 2MHz.
> 
> and yes I play some more with the global nets, they seem to be a key
> in Actel technology.

If this is clocked from a uC, one thing you could do, is add
a loop readback - where you either simply use the SR as
a delay line, and check you get back what left 64 clocks ago,
or add a Load option, so you can read back any latched nodes,
to verify their content ?

-jg


Article: 125223
Subject: What to consider for source synchronous clocking?
From: Ben <leowyuan@gmail.com>
Date: Thu, 18 Oct 2007 09:53:23 -0000
Links: << >>  << T >>  << A >>
Hi everyone, pardon me but I'm pretty new to this.

I'm using a Spartan 3 right now, and I'm trying to provide source
synchronous clock clocking to a SDR SDRAM using DDR register.
The component looks something like this:

OFDDRCPE sdram0OutputClock (
	.Q(sdram0_clk),
	.C0(sdram_clk),
	.C1(~sdram_clk),
	.CE(1'b1),
	.CLR(1'b0),
	.D0(1'b1),
	.D1(1'b0),
	.PRE(1'b0) );

The input clock is sdram_clk and the output clock to the sdram is
sdram0_clk
The problem is I'm not sure whether I need to specify any extra
constraints in the UCF file for sdram0_clk.
Is there anything else to take note of?
Are sdram_clk and sdram0_clk considered as different clock domains? If
so how do I get the data back to the sdram_clk domain?

Thanks in advance,
Ben.


Article: 125224
Subject: xilinx Edititons
From: xenix <lastval@gmail.com>
Date: Thu, 18 Oct 2007 10:27:38 -0000
Links: << >>  << T >>  << A >>
Hello all, I would like to ask if i can install in my computer 2
different versions of EDK, one older than the other.

O/S : Windows XP

regards
xenix




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search