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 154875

Article: 154875
Subject: JTAG, CONF_DONE failed to go high in device 1.
From: "tramalo" <4074@embeddedrelated>
Date: Fri, 25 Jan 2013 08:35:22 -0600
Links: << >>  << T >>  << A >>
This is actually a re-post of my thread on alteraforum.com. 
( www.alteraforum.com/forum/showthread.php?t=39255&p=161811#post161811 )
Having got no answers I'll post here as well.

Before anyone comments on this, I have searched the forum and read
everything I have found on the internet with people getting this error
message. 
I'll try to post as much relevant information as possible, so the next one
who has this problem might get off a bit easier.

"Error (209014): CONF_DONE failed to go high in device 1"

The error message happens both when trying to program the Serial Flash
Loader and when trying to program JTAG directly. The programming fails
before there is any progress, it doesn't even say 0%. 
Auto Detect Device functions as it should though. I get the choice between
EP4CE15 and EP3C16, but that has never been a problem with other designs.


I have made a custom board with a FBGA256 Cyclone IV EP4CE15 fpga and some
peripherals. 
The fpga is hooked up with JTAG for Serial Flash Loader (SFL) as described
in the Device Handbook on page 218 (figure 8-29, revision november 2011).


I'm using a 20MHz CMOS oscillator, although that shouldn't have any impact
on this issue as far as I know. 


The supply voltages are derived through separate low-noise, high PSRR
LDO-regulators which can deliver max 150mA each. 
They are connected as such:
VCCIO of all IO-bank is 3,3V. 
VCCINT is 1,2V.
VCCD_PLL and VCCA is 2,5V


nCE (J3) is connected to ground. 
nStatus (F4), nConfig (H5) and CONF_DONE (H14) are all pulled to VCCIO by
10k resistors.


MSEL are connected as MSEL0(H13)=2,5V, MSEL1(H12)=GND, MSEL2(G12)=GND. But
since I'm using JTAG these would be overridden anyways.


The JTAG plug is connected as such:
1 - TCK (pin H3), pulled to GND by 1k
2 - GND
3 - TDO (pin J4)
4 - 2,5V
5 - TMS (pin J5), pulled to VCCIO by 10k
6 - 2,5V
7,8 - N.C.
9 - TDI (pin H4), pulled to VCCIO by 10k
10 - GND


Does anyone know anything I can try?

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154876
Subject: Re: JTAG, CONF_DONE failed to go high in device 1.
From: "tramalo" <4074@embeddedrelated>
Date: Fri, 25 Jan 2013 08:48:09 -0600
Links: << >>  << T >>  << A >>
>The supply voltages are derived through separate low-noise, high PSRR
>LDO-regulators which can deliver max 150mA each. 
>They are connected as such:
>VCCIO of all IO-bank is 3,3V. 
>VCCINT is 1,2V.
>VCCD_PLL and VCCA is 2,5V
>

VCCD_PLL is actually 1,2V.


>The JTAG plug is connected as such:
>1 - TCK (pin H3), pulled to GND by 1k
>2 - GND
>3 - TDO (pin J4)
>4 - 2,5V
>5 - TMS (pin J5), pulled to VCCIO by 10k
>6 - 2,5V
>7,8 - N.C.
>9 - TDI (pin H4), pulled to VCCIO by 10k
>10 - GND

Pin 6 is actually a N.C. as well.
I have also tried pulling 5 and 9 to VCCA in stead with no effect.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154877
Subject: Re: JTAG, CONF_DONE failed to go high in device 1.
From: "tramalo" <4074@embeddedrelated>
Date: Fri, 25 Jan 2013 08:50:33 -0600
Links: << >>  << T >>  << A >>
Things I have noticed: 
1. DEV_OE and INIT_DONE are each connected to a LED to ground with 470ohm
resistors. They light up for a moment when I click the program-button in
the Device Programmer. They both give 3,3V.

- When INIT_DONE lights up, this should mean that the FPGA has entered
"User Mode". But what does it mean when it goes high for a moment and then
low again? 
Might this be the registers initializing to a high value or something like
that before configuration?

More things I have tried:
2. Checking the box for Compressed Bitstream. No change.
3. Enabling device-wide output enable (DEV_OE) and reset (DEV_CLRn) as per
suggestions in another thread. No change.
4. Disconnecting the LEDs on DEV_OE and INIT_DONE, suspecting they'd
overload the output. No change.
5. Tried pulling CONF_DONE high by a 1k resistor instead of 10k. No
change.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154878
Subject: ip core implementation on fpga
From: deepak <dpk.losser@gmail.com>
Date: Fri, 25 Jan 2013 10:22:06 -0800 (PST)
Links: << >>  << T >>  << A >>
ERROR:PhysDesignRules:368 - The signal <p<0>_OBUF> is incomplete. The signal is
   not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <p<1>_OBUF> is incomplete. The signal is
   not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <p<2>_OBUF> is incomplete. The signal is
   not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal <p<3>_OBUF> is incomplete. The signal is
   not driven by any source pin in the design.
ERROR:PhysDesignRules:10 - The network <p<0>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <p<1>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <p<2>_OBUF> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <p<3>_OBUF> is completely unrouted.
ERROR:Bitgen:25 - DRC detected 8 errors and 5 warnings.  Please see the
   previously displayed individual error or warning messages for more details.


these are the errors i am getting while i am trying to run the ip core of multiplication on spartan 3e.its giving me output on ism(behavioral simulation)
but giving these errors while i am trying to run it througf fpga.can someone help??

Article: 154879
Subject: Re: ip core implementation on fpga
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 25 Jan 2013 13:40:23 -0500
Links: << >>  << T >>  << A >>
deepak wrote:
> ERROR:PhysDesignRules:368 - The signal <p<0>_OBUF> is incomplete. The signal is
>    not driven by any source pin in the design.
> ERROR:PhysDesignRules:368 - The signal <p<1>_OBUF> is incomplete. The signal is
>    not driven by any source pin in the design.
> ERROR:PhysDesignRules:368 - The signal <p<2>_OBUF> is incomplete. The signal is
>    not driven by any source pin in the design.
> ERROR:PhysDesignRules:368 - The signal <p<3>_OBUF> is incomplete. The signal is
>    not driven by any source pin in the design.
> ERROR:PhysDesignRules:10 - The network <p<0>_OBUF> is completely unrouted.
> ERROR:PhysDesignRules:10 - The network <p<1>_OBUF> is completely unrouted.
> ERROR:PhysDesignRules:10 - The network <p<2>_OBUF> is completely unrouted.
> ERROR:PhysDesignRules:10 - The network <p<3>_OBUF> is completely unrouted.
> ERROR:Bitgen:25 - DRC detected 8 errors and 5 warnings.  Please see the
>    previously displayed individual error or warning messages for more details.
> 
> 
> these are the errors i am getting while i am trying to run the ip core of multiplication on spartan 3e.its giving me output on ism(behavioral simulation)
> but giving these errors while i am trying to run it througf fpga.can someone help??

Apparently you have a top level output port p[3:0] that is not
ever driven by the design.  In older versions of ISE, any undriven
output was tied to ground.  Given that in a real piece of hardware,
unintentionally undriven outputs could cause board-level problems
if arbitrarily connected to ground, newer versions of ISE leave them
unrouted and then you will fail design rule check (DRC) when you
go to create the project.  You need to either connect this output
port to something in the design, or remove it.

-- Gabor

Article: 154880
Subject: Re: Ray Andraka's Book?
From: Paul Colin Gloster <Colin_Paul_Gloster@ACM.org>
Date: Sat, 26 Jan 2013 21:23:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2013-01-25, Dldatwyler@GMail.com sent:
|---------------------------------------------------------------------------|
|"I noticed this very old post about the "book". Is it to be published soon?|
|                                                                           |
|                                                                           |
|On Wednesday, February 22, 2006 9:28:42 AM UTC-7, Ray Andraka wrote:       |
|> Stephen Craven wrote:                                                    |
|> > Last summer mention was made of a DSP / FPGA book by Ray Andraka       |
|> > hitting the (online) shelves this fall:                                |
|> > http://tinyurl.com/s4v5s                                               |
|> >                                                                        |
|> > Has this come to pass?                                                 |
|> >                                                                        |
|> > Aside from Meyer-Baese's "Digital Signal Processing with Field         |
|> > Programmable Gate Arrays" book, which I found somewhat difficult to    |
|> > read, are there any other FPGA-specific DSP books out there?           |
|> >                                                                        |
|> > Thanks!                                                                |
|> > Stephen                                                                |
|> >                                                                        |
|>                                                                          |
|> No, unfortunately, I am still working on it, and my publisher (elsevier) |
|> is sitting on my rather firmly to get it done.  Only so many hours per   |
|> day.  They have set a new deadline for me to have it to them by August   |
|> so that they can get it out in the fall."                                |
|---------------------------------------------------------------------------|


I was not aware of this book but I am aware of Ray Andraka and he is
very competent. You could ask him yourself:
WWW.Andraka.com

Article: 154881
Subject: Re: Ray Andraka's Book?
From: Michael S <already5chosen@yahoo.com>
Date: Sat, 26 Jan 2013 14:27:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 26, 11:23=A0pm, Paul Colin Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> On 2013-01-25, Dldatwy...@GMail.com sent:
> |------------------------------------------------------------------------=
---|
> |"I noticed this very old post about the "book". Is it to be published so=
on?|
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 |
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 |
> |On Wednesday, February 22, 2006 9:28:42 AM UTC-7, Ray Andraka wrote: =A0=
 =A0 =A0 ||> Stephen Craven wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>
> |> > Last summer mention was made of a DSP / FPGA book by Ray Andraka =A0=
 =A0 =A0 |
> |> > hitting the (online) shelves this fall: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> |> >http://tinyurl.com/s4v5s=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> |> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
|
> |> > Has this come to pass? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> |> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
|
> |> > Aside from Meyer-Baese's "Digital Signal Processing with Field =A0 =
=A0 =A0 =A0 |
> |> > Programmable Gate Arrays" book, which I found somewhat difficult to =
=A0 =A0|
> |> > read, are there any other FPGA-specific DSP books out there? =A0 =A0=
 =A0 =A0 =A0 |
> |> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
|
> |> > Thanks! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> |> > Stephen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> |> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
|
> |> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0|
> |> No, unfortunately, I am still working on it, and my publisher (elsevie=
r) |
> |> is sitting on my rather firmly to get it done. =A0Only so many hours p=
er =A0 |
> |> day. =A0They have set a new deadline for me to have it to them by Augu=
st =A0 |
> |> so that they can get it out in the fall." =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> |------------------------------------------------------------------------=
---|
>
> I was not aware of this book but I am aware of Ray Andraka and he is
> very competent. You could ask him yourself:
> WWW.Andraka.com

I am afraid, many 2005 techniques, like, for example, cordix,
distributed arithmetics, utilization of SRL16 for delay lines, are not
relevant today, when even low end FPGAs have plenty of hard
multipliers and embedded memory blocks.

Article: 154882
Subject: Sometimes I Just Don't Get the Tools
From: rickman <gnuarm@gmail.com>
Date: Sun, 27 Jan 2013 22:46:05 -0500
Links: << >>  << T >>  << A >>
I've learned to use Active HDL some time ago and never had too much 
trouble with it. But now it is not letting me use the waveform viewer in 
an effective way.  I typically add all my signals once and then as I 
work on the design and recompile it uses the same signal on each 
iteration of the edit/compile/simulate cycle.

Now it is deleting all my signals from the waveform every time I 
recompile.  Seems it is related to using the "advanced waveform editor". 
  I found a setting that says, "preserve signals when simulation is 
initialized".  WTF?  I guess if you are doing everything from a 
simulation batch file you just add these signals too, but what is the 
purpose of automatically deleting them by default or at all?  I would 
think a batch file could easily delete any existing signals before 
creating its display.

Sometimes I just don't get the mindset of the tool developers.

Rick

Article: 154883
Subject: Re: Sometimes I Just Don't Get the Tools
From: valtih1978 <do@not.email.me>
Date: Mon, 28 Jan 2013 14:08:45 +0200
Links: << >>  << T >>  << A >>
> Now it is deleting all my signals from the waveform every time I
> recompile.  Seems it is related to using the "advanced waveform editor".

This option has always infuriated me. Thanks for saying that the problem 
is the tool, not me.


Article: 154884
Subject: Re: Sometimes I Just Don't Get the Tools
From: joshrsmith@gmail.com
Date: Mon, 28 Jan 2013 06:01:00 -0800 (PST)
Links: << >>  << T >>  << A >>
I believe the "preserve" option was not even available after they first int=
roduced the Advanced waveform viewer. I am going to guess that the reason t=
hat signals were not preserved was related to a software implementation dif=
ficulty, and had little to do with the "user experience"...

Article: 154885
Subject: DSP in FPGA (was Re: Ray Andraka's Book?)
From: Christopher Felton <nospam@nowhere.com>
Date: Mon, 28 Jan 2013 08:34:52 -0600
Links: << >>  << T >>  << A >>
On 1/26/2013 4:27 PM, Michael S wrote:
> On Jan 26, 11:23 pm, Paul Colin Gloster <Colin_Paul_Glos...@ACM.org>
> wrote:
>> On 2013-01-25, Dldatwy...@GMail.com sent:
>> |---------------------------------------------------------------------------|
>> |"I noticed this very old post about the "book". Is it to be published soon?|
>> |                                                                           |
>> |                                                                           |
>> |On Wednesday, February 22, 2006 9:28:42 AM UTC-7, Ray Andraka wrote:       ||> Stephen Craven wrote:                                                    |
>>
>> |> > Last summer mention was made of a DSP / FPGA book by Ray Andraka       |
>> |> > hitting the (online) shelves this fall:                                |
>> |> >http://tinyurl.com/s4v5s                                              |
>> |> >                                                                        |
>> |> > Has this come to pass?                                                 |
>> |> >                                                                        |
>> |> > Aside from Meyer-Baese's "Digital Signal Processing with Field         |
>> |> > Programmable Gate Arrays" book, which I found somewhat difficult to    |
>> |> > read, are there any other FPGA-specific DSP books out there?           |
>> |> >                                                                        |
>> |> > Thanks!                                                                |
>> |> > Stephen                                                                |
>> |> >                                                                        |
>> |>                                                                          |
>> |> No, unfortunately, I am still working on it, and my publisher (elsevier) |
>> |> is sitting on my rather firmly to get it done.  Only so many hours per   |
>> |> day.  They have set a new deadline for me to have it to them by August   |
>> |> so that they can get it out in the fall."                                |
>> |---------------------------------------------------------------------------|
>>
>> I was not aware of this book but I am aware of Ray Andraka and he is
>> very competent. You could ask him yourself:
>> WWW.Andraka.com
>
> I am afraid, many 2005 techniques, like, for example, cordix,
> distributed arithmetics, utilization of SRL16 for delay lines, are not
> relevant today, when even low end FPGAs have plenty of hard
> multipliers and embedded memory blocks.
>

I disagree in some cases, although multipliers are bountiful,
relatively speaking.  Many applications have no problem using
up all the multipliers and still unsatisfied.  Being able
to calculate an arctan with a pipelined cordic is still
relevant.

Regards,
Chris


Article: 154886
Subject: Re: Sometimes I Just Don't Get the Tools
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 28 Jan 2013 09:16:21 -0800
Links: << >>  << T >>  << A >>
On Sun, 27 Jan 2013 22:46:05 -0500
rickman <gnuarm@gmail.com> wrote:

> I've learned to use Active HDL some time ago and never had too much 
> trouble with it. But now it is not letting me use the waveform viewer in 
> an effective way.  I typically add all my signals once and then as I 
> work on the design and recompile it uses the same signal on each 
> iteration of the edit/compile/simulate cycle.
> 
> Now it is deleting all my signals from the waveform every time I 
> recompile.  Seems it is related to using the "advanced waveform editor". 
>   I found a setting that says, "preserve signals when simulation is 
> initialized".  WTF?  I guess if you are doing everything from a 
> simulation batch file you just add these signals too, but what is the 
> purpose of automatically deleting them by default or at all?  I would 
> think a batch file could easily delete any existing signals before 
> creating its display.
> 
> Sometimes I just don't get the mindset of the tool developers.
> 
> Rick

In my college transistor circuits course, back shortly before the
discovery of electricity, we were targetting -100dB THD, and verifying
against a distortion analyzer.  Look at it on a scope, sine wave.  Look
at it on the analyzer, nuthin'.  Back and forth, over and over, for
10 minutes we couldn't get any results out of the distortion analyzer.

Turned out to have a tiny button next to the BNC called "Input
Disconnect".  Or as we called it, the Broken button.  Since then I've
been amazed at how many designers of how many things have felt the need
to include a Broken button.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 154887
Subject: Re: Sometimes I Just Don't Get the Tools
From: rickman <gnuarm@gmail.com>
Date: Mon, 28 Jan 2013 16:51:53 -0500
Links: << >>  << T >>  << A >>
On 1/28/2013 12:16 PM, Rob Gaddi wrote:
> On Sun, 27 Jan 2013 22:46:05 -0500
> rickman<gnuarm@gmail.com>  wrote:
>
>> I've learned to use Active HDL some time ago and never had too much
>> trouble with it. But now it is not letting me use the waveform viewer in
>> an effective way.  I typically add all my signals once and then as I
>> work on the design and recompile it uses the same signal on each
>> iteration of the edit/compile/simulate cycle.
>>
>> Now it is deleting all my signals from the waveform every time I
>> recompile.  Seems it is related to using the "advanced waveform editor".
>>    I found a setting that says, "preserve signals when simulation is
>> initialized".  WTF?  I guess if you are doing everything from a
>> simulation batch file you just add these signals too, but what is the
>> purpose of automatically deleting them by default or at all?  I would
>> think a batch file could easily delete any existing signals before
>> creating its display.
>>
>> Sometimes I just don't get the mindset of the tool developers.
>>
>> Rick
>
> In my college transistor circuits course, back shortly before the
> discovery of electricity, we were targetting -100dB THD, and verifying
> against a distortion analyzer.  Look at it on a scope, sine wave.  Look
> at it on the analyzer, nuthin'.  Back and forth, over and over, for
> 10 minutes we couldn't get any results out of the distortion analyzer.
>
> Turned out to have a tiny button next to the BNC called "Input
> Disconnect".  Or as we called it, the Broken button.  Since then I've
> been amazed at how many designers of how many things have felt the need
> to include a Broken button.
>

They charge extra for buttons on test gear, don't they... no matter how 
banal...

I'm still struggling with this issue, but in a more limited scope.  When 
I compile bad code in a way that causes the tool to get upset enough to 
forget what the top level module is, on fixing the problem and starting 
the simulation the waveform display any variables on display can't be 
found in the code and are deleted... stupid tools!

I guess my real issue is that I had been using an older version of the 
tool and for whatever reason I'm pretty sure I wasn't allowed to use the 
"advanced" waveform viewer.  Now that I am using the *advanced* viewer, 
I am finding that it is only advanced in some ways that I don't actually 
perceive.  I guess it might be faster.  The simulations seem to run a 
lot faster than with the old tool, but I'm comparing apples and oranges 
in terms of the project.  This one is still pretty small and is only 
running at a quarter MHz.

At least I am learning to not "upset* the tools.  Otherwise they try to 
get revenge... spiteful tools!

Rick

Article: 154888
Subject: Re: DSP in FPGA (was Re: Ray Andraka's Book?)
From: rickman <gnuarm@gmail.com>
Date: Mon, 28 Jan 2013 16:57:37 -0500
Links: << >>  << T >>  << A >>
On 1/28/2013 9:34 AM, Christopher Felton wrote:
> On 1/26/2013 4:27 PM, Michael S wrote:
>> On Jan 26, 11:23 pm, Paul Colin Gloster <Colin_Paul_Glos...@ACM.org>
>>>
>>> I was not aware of this book but I am aware of Ray Andraka and he is
>>> very competent. You could ask him yourself:
>>> WWW.Andraka.com
>>
>> I am afraid, many 2005 techniques, like, for example, cordix,
>> distributed arithmetics, utilization of SRL16 for delay lines, are not
>> relevant today, when even low end FPGAs have plenty of hard
>> multipliers and embedded memory blocks.
>>
>
> I disagree in some cases, although multipliers are bountiful,
> relatively speaking. Many applications have no problem using
> up all the multipliers and still unsatisfied. Being able
> to calculate an arctan with a pipelined cordic is still
> relevant.

Yeah, and not all FPGA projects use gargantuan devices that dim the city 
when powered up.  I am right by a nuclear power plant and I can hear the 
turbines groan when some of you guys run your designs.

I'm currently working on a powerless design.  It will be so low power it 
scavenges power from stray electrons, quanta and fields, maybe even 
thermal gradients.  I could power it from the glow of some of the high 
end FPGA designs, or even the convection air currents!

Yes, I think CORDIC is still useful, although I plan to do it with a 
table lookup... I can live with six bits out.

Rick

Article: 154889
Subject: Re: Sometimes I Just Don't Get the Tools
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 28 Jan 2013 22:24:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:

(snip, someone wrote)
>> Turned out to have a tiny button next to the BNC called "Input
>> Disconnect".  Or as we called it, the Broken button.  Since then I've
>> been amazed at how many designers of how many things have felt the need
>> to include a Broken button.
 
> They charge extra for buttons on test gear, don't they... no matter how 
> banal...

I suppose, but more buttons means that marketing can advertize
them as additional features.

Reminds me of the hardest to find button on most oscilloscopes,
the on/off button (or knob or ...).

-- glen

Article: 154890
Subject: Re: DSP in FPGA (was Re: Ray Andraka's Book?)
From: Christopher Felton <abc@def.org>
Date: Mon, 28 Jan 2013 21:46:12 -0600
Links: << >>  << T >>  << A >>
On 1/28/13 3:57 PM, rickman wrote:
> On 1/28/2013 9:34 AM, Christopher Felton wrote:
>> On 1/26/2013 4:27 PM, Michael S wrote:
>>> On Jan 26, 11:23 pm, Paul Colin Gloster <Colin_Paul_Glos...@ACM.org>
>>>>
>>>> I was not aware of this book but I am aware of Ray Andraka and he is
>>>> very competent. You could ask him yourself:
>>>> WWW.Andraka.com
>>>
>>> I am afraid, many 2005 techniques, like, for example, cordix,
>>> distributed arithmetics, utilization of SRL16 for delay lines, are not
>>> relevant today, when even low end FPGAs have plenty of hard
>>> multipliers and embedded memory blocks.
>>>
>>
>> I disagree in some cases, although multipliers are bountiful,
>> relatively speaking. Many applications have no problem using
>> up all the multipliers and still unsatisfied. Being able
>> to calculate an arctan with a pipelined cordic is still
>> relevant.
>
> Yeah, and not all FPGA projects use gargantuan devices that dim the city
> when powered up.  I am right by a nuclear power plant and I can hear the
> turbines groan when some of you guys run your designs.
>
> I'm currently working on a powerless design.  It will be so low power it
> scavenges power from stray electrons, quanta and fields, maybe even
> thermal gradients.  I could power it from the glow of some of the high
> end FPGA designs, or even the convection air currents!
>
> Yes, I think CORDIC is still useful, although I plan to do it with a
> table lookup... I can live with six bits out.
>
> Rick

I agree as well, I imagine there are many low-power low
resource designs.  A good book on DSP in FPGAs will cover
both ends of the spectrum.  How to easily use up all the
multiplier resources as well as all the neat little tricks
to save resources/power.

What I don't like in books like this is device specific
information.  Seems pointless to provide specific FPGA
architectures (changes too often).  Just need the generic
view of the architecture not the specific slice organization,
or optimization on device specific components, again it should
talk in device generalities.

Regards,
Chris



Article: 154891
Subject: Re: Sometimes I Just Don't Get the Tools
From: valtih1978 <do@not.email.me>
Date: Tue, 29 Jan 2013 14:14:55 +0200
Links: << >>  << T >>  << A >>
On 28.01.2013 23:51, rickman wrote:
> I'm still struggling with this issue, but in a more limited scope.  When
> I compile bad code in a way that causes the tool to get upset enough to
> forget what the top level module is, on fixing the problem and starting
> the simulation the waveform display any variables on display can't be
> found in the code and are deleted... stupid tools!

I remember it was loosing everything when (re)compiled a package.

Article: 154892
Subject: Re: Ray Andraka's Book?
From: jonesandy@comcast.net
Date: Tue, 29 Jan 2013 06:33:27 -0800 (PST)
Links: << >>  << T >>  << A >>
If I had a nickel for every time I've heard throughout my career about this=
 or that technology no longer being relevant...

Technology is like fashion: whatever is old will be new again someday, with=
 a new spin and a new relevance. Don't throw it away; just keep it in the b=
ack of your closet, and you will be able to use it again. And for those tha=
t missed it the first time around, the second-hand stores are always full o=
f these still-useful articles from bygone times.

I remember my college digital design coursework included implementing boole=
an logic functions with multiplexers and decoders. Then PALs came along and=
 changed that to sum-of-products. Then FPGAs came along and changed it back=
 (pre-HDL). Then HDL came along and changed it again.

The Cordic algorithms were not new when FPGAs came along. They were dusted =
off from the ancient spells of the priests of the order of multiplierless m=
icroprocessors and "pieces of eight". And those priests were probably taugh=
t their craft by the wizards of relays and vacuum tubes.

Andy


Article: 154893
Subject: Re: Sometimes I Just Don't Get the Tools
From: rickman <gnuarm@gmail.com>
Date: Tue, 29 Jan 2013 20:07:08 -0500
Links: << >>  << T >>  << A >>
On 1/29/2013 7:14 AM, valtih1978 wrote:
> On 28.01.2013 23:51, rickman wrote:
>> I'm still struggling with this issue, but in a more limited scope. When
>> I compile bad code in a way that causes the tool to get upset enough to
>> forget what the top level module is, on fixing the problem and starting
>> the simulation the waveform display any variables on display can't be
>> found in the code and are deleted... stupid tools!
>
> I remember it was loosing everything when (re)compiled a package.

When I used the Active simulator before it would not delete signals from 
the waveform display no matter what.  I would eventually notice that a 
signal was not showing a waveform, most likely because I had deleted the 
signal from the code, and remove it from the display.

I can't say much about variables in the waveform viewer.  I don't recall 
having any problems with them, but I've not typically used them a lot, 
at least I didn't have a lot of need to show their waveforms.  I seem to 
be using them more now and for more "important" signals.  My test 
benches are full of them and now I'm having these problems.

I would consider using a macro to add everything to the waveform 
display, I think there is even a menu command to save the current 
waveform setup as a .do file.  But only the variables seem to be lost 
now and only after starting the simulation.  The .do file would have to 
start the simulation, stop it immediately, delete all signals from the 
waveform display, add them all back and then restart the simulation... 
really?

There has to be a better way.

Rick

Article: 154894
Subject: Re: Sometimes I Just Don't Get the Tools
From: rickman <gnuarm@gmail.com>
Date: Thu, 31 Jan 2013 00:39:09 -0500
Links: << >>  << T >>  << A >>
On 1/29/2013 8:07 PM, rickman wrote:
> On 1/29/2013 7:14 AM, valtih1978 wrote:
>> On 28.01.2013 23:51, rickman wrote:
>>> I'm still struggling with this issue, but in a more limited scope. When
>>> I compile bad code in a way that causes the tool to get upset enough to
>>> forget what the top level module is, on fixing the problem and starting
>>> the simulation the waveform display any variables on display can't be
>>> found in the code and are deleted... stupid tools!
>>
>> I remember it was loosing everything when (re)compiled a package.
>
> When I used the Active simulator before it would not delete signals from
> the waveform display no matter what. I would eventually notice that a
> signal was not showing a waveform, most likely because I had deleted the
> signal from the code, and remove it from the display.
>
> I can't say much about variables in the waveform viewer. I don't recall
> having any problems with them, but I've not typically used them a lot,
> at least I didn't have a lot of need to show their waveforms. I seem to
> be using them more now and for more "important" signals. My test benches
> are full of them and now I'm having these problems.
>
> I would consider using a macro to add everything to the waveform
> display, I think there is even a menu command to save the current
> waveform setup as a .do file. But only the variables seem to be lost now
> and only after starting the simulation. The .do file would have to start
> the simulation, stop it immediately, delete all signals from the
> waveform display, add them all back and then restart the simulation...
> really?
>
> There has to be a better way.

Ok, some of the mystery has been lifted.  I found a way to automatically 
create a macro to add all your signals to the display, but it still 
didn't solve the problem.  But while I was looking at the text in the 
macro file, I noticed that the path for the variables that were being 
lost contained a line number reference!  When a variable is declared in 
a process, it is given a path name to that process.  If you don't assign 
a label, it just uses a line number.  When that line number changes, the 
path is no longer valid and the variables disappear!

I often start off without labels on most objects in my code and add them 
later when I am tidying up.  Now I see I need to add them up front. 
Heck, VHDL lets you label every concurrent statement in the code since 
they are all processes really.  Not that there is a lot of need for 
that.  I didn't see much of this before because I wasn't using variables 
so much.  Actually, a number of variables just got the axe.  Sometimes 
they need to be accessed outside of the process and sometimes I prefer 
to make them concurrent assignments when that works just as well.

-- 

Rick

Article: 154895
Subject: Re: Combination loops and false paths
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 31 Jan 2013 17:30:38 -0600
Links: << >>  << T >>  << A >>
Rob Doyle wrote:


> 
> I guess that it is just a design from another day - a whole lot less
> synchronous than anything I've done in an FPGA before.
> 
Yes, some PDP-10s were not rigidly clocked at all, so that when there were
no carries from the ALU after a few ns, the operation was considered
complete and the result stored.  Really nasty way to design a machine!

> I have enjoyed going back through that all.   I even found my "Mick and
> Brick" book.  I'll probably do a VAX 11/780 next which also used
> bit-sliced parts.
No, not true.  The 780 was all 74S chips (some LS on non-critical paths)
but nothing LSI at all.  The 730 and 750 used TI mask-programmed logic
array parts.  I actually read the print set of a 780 about 30 years ago
and at one time knew the design pretty well.

Jon

Article: 154896
Subject: Re: Combination loops and false paths
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 1 Feb 2013 04:27:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jon Elson <jmelson@wustl.edu> wrote:

(snip)
>> I guess that it is just a design from another day - a whole lot less
>> synchronous than anything I've done in an FPGA before.
 
> Yes, some PDP-10s were not rigidly clocked at all, so that when there were
> no carries from the ALU after a few ns, the operation was considered
> complete and the result stored.  Really nasty way to design a machine!
 
>> I have enjoyed going back through that all.   I even found my "Mick and
>> Brick" book.  I'll probably do a VAX 11/780 next which also used
>> bit-sliced parts.

> No, not true.  The 780 was all 74S chips (some LS on non-critical paths)
> but nothing LSI at all.  The 730 and 750 used TI mask-programmed logic
> array parts.  I actually read the print set of a 780 about 30 years ago
> and at one time knew the design pretty well.

Story I knew from about 30 years ago was that the 730 was build
from 2900 series parts. That was supposed to be related to 
H-float being included, (no extra charge) when it wasn't for
the earlier models. So, H-float on the 730 was faster than the
software emulation on the 750. (But then again, I never tried.)

-- glen

Article: 154897
Subject: Re: MicroBlaze MCS Error.
From: andreprado88@gmail.com
Date: Fri, 1 Feb 2013 03:18:39 -0800 (PST)
Links: << >>  << T >>  << A >>
i have the same problem and i've followed the xilinx manual.
Em domingo, 22 de janeiro de 2012 13h01min34s UTC-2, =E3=83=90=E3=82=B5=E3=
=83=AD  escreveu:
> Hi all.
>=20
> I'm T.Koyama.
>=20
>=20
>=20
> I download ISE 13.4 and make IP Microblze mcs.
>=20
> I could make IP and bitstream,and I make ELF file under SDK
>=20
> So I will download to FPGA, but Error ocuuer.
>=20
>=20
>=20
> Error meaaseg is "ERROR:Data2MEM:47 - Not all BitLanes in
>=20
> ADDRESS_SPACE 'mb_mcs.lmb_bram' have BMM location constraints."
>=20
>=20
>=20
> Do you know What happend.
>=20
>=20
>=20
> T . Koyama.


Article: 154898
Subject: Using CAN on Zynq
From: =?ISO-8859-1?Q?Heinz=2DJ=FCrgen?= Oertel <hj.oertel@t-online.de>
Date: Fri, 01 Feb 2013 18:01:56 +0100
Links: << >>  << T >>  << A >>
Hello,
might not be a real FPGA question,
but I hope that some of you doing not only the hardware part
but also working with the Xilinx SDK.
I try to use the CAN controller on e ZedBoard under Linux.
I *think* that I have done the CAN_L and CAN_H routing correct 
to the FMC connector. Now I read and write to the CAN controller registers.
It seems to be correct, if I look what I'm reading back.
BUT, nothing happens at the CAN lines at the FMC connector.
What am I missing?
Do I need special clock settings in some other register, not CAN.
Or What else has to be programmed in order to get the CAN working?

Best regards
    Heinz


Article: 154899
Subject: Re: Using CAN on Zynq
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 04 Feb 2013 13:43:15 +0000
Links: << >>  << T >>  << A >>
Heinz-Jürgen Oertel <hj.oertel@t-online.de> writes:

> Hello,
> might not be a real FPGA question,
> but I hope that some of you doing not only the hardware part
> but also working with the Xilinx SDK.
> I try to use the CAN controller on e ZedBoard under Linux.
> I *think* that I have done the CAN_L and CAN_H routing correct 
> to the FMC connector. Now I read and write to the CAN controller registers.
> It seems to be correct, if I look what I'm reading back.
> BUT, nothing happens at the CAN lines at the FMC connector.
> What am I missing?
> Do I need special clock settings in some other register, not CAN.
> Or What else has to be programmed in order to get the CAN working?

AFAIK, the Zedboard has no CAN physical layer on - how did you turn your
CAN Tx and Rx into CAN_H and CAN_L?

The CAN checklist goes:

* Have you got all the same "type" of PHY (there are high-speed,
  low-speed, single-wire etc. variants)

* If high-speed, is the bus using twisted pair wiring?

* Is the bus a sensible length ("sensible" depends on bit-rate, wire
  quality, and sundry other issues, so start with a small bus on the
  bench ~2m)

* Is the bus terminated correctly?

* Have you another node on the bus to acknowledge the transmissions?

* Are all the nodes running with the same bit width and sampling point?

* Is the bus noise-free?

Do you have any CAN analysis tools (Canalyzer for example, or a
scope/logic analyser that understands the protocol)?

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware



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