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 142950

Article: 142950
Subject: Re: Bidirectional Bus
From: nobody <cydrollinger@gmail.com>
Date: Wed, 9 Sep 2009 15:18:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
Antti,

Do not want to raise any hackles, but you are correct about the
demandperipherials knock off, perceptive. I talked with Bob Smith
about a couple of things and he basically said go away, I understand
and with no further ado I did. Here is a picture of my finished
product, http://www.mediafire.com/?sharekey=923066edf8d516eeed24a2875c7fa58ee04e75f6e8ebb871

I agree about the so simple part, However there is something
interesting in this problem I have described, I just have not found
it.

SPI works fine and is not part of the usb programming, indirect JTAG
only.

I am not sure how the FT245RL can strobe its own read line and produce
a CCLK in order to load the data into FPGA, if you are willing to
elaborate im willing to read.

I went for a swim to clear my head it works every time.

Will give your suggestions a closer look.

I have so much completed on this board from absolutely nothing to 95%
working it is a great project and will be taking this open source. I
wonder why my work is not necessary?

Antti, thanks for chatting not looking to raise any hackles, but am
glad for the help.

Cy Drollinger

Article: 142951
Subject: Re: Xilinx TCL and Cygwin
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 09 Sep 2009 15:29:22 -0700
Links: << >>  << T >>  << A >>
Rob Gaddi wrote:
> I was just starting to try to do some playing with TCL, and ran into an
> interesting problem.  If you're running bash through Cygwin:

cygwin is a time bandit.
try cmd.exe  tcl or wish
or modelsim transcript
or linux bash.
Good luck.

    -- Mike Treseler

Article: 142952
Subject: Re: Bidirectional Bus
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Wed, 9 Sep 2009 22:02:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 10, 1:18=A0am, nobody <cydrollin...@gmail.com> wrote:
> Antti,
>
> Do not want to raise any hackles, but you are correct about the
> demandperipherials knock off, perceptive. I talked with Bob Smith
> about a couple of things and he basically said go away, I understand
> and with no further ado I did. Here is a picture of my finished
> product,http://www.mediafire.com/?sharekey=3D923066edf8d516eeed24a2875c7f=
a58ee0...
>
> I agree about the so simple part, However there is something
> interesting in this problem I have described, I just have not found
> it.
>
> SPI works fine and is not part of the usb programming, indirect JTAG
> only.
>
> I am not sure how the FT245RL can strobe its own read line and produce
> a CCLK in order to load the data into FPGA, if you are willing to
> elaborate im willing to read.
>
> I went for a swim to clear my head it works every time.
>
> Will give your suggestions a closer look.
>
> I have so much completed on this board from absolutely nothing to 95%
> working it is a great project and will be taking this open source. I
> wonder why my work is not necessary?
>
> Antti, thanks for chatting not looking to raise any hackles, but am
> glad for the help.
>
> Cy Drollinger

Cy

pretty much NO ONE in the open-source community is inteterested in 4
layer PCB with S3E
ALL S3E board level products are DISCONTINUED by Xilinx
if Xilinx has discontinued, why do you want to promote something
Xilinx itself wants to forget?

your board is TOO expensive

option:

step 1:
take S3AN add LDO, and RJ45 jack and 100 mil header
PCB should be REAL simple and 2 layers only

step 2:
ask U2TOOL OEM pricing (coming soon www.u2tool.com )

step 3:
bundle items [1] and [2]

you can do step 2 before step 1 :)

Antti

Article: 142953
Subject: Re: Traversing hierarchy in UCF works for OBUF, but not IOBUF, please
From: Telenochek <elet.mirror@gmail.com>
Date: Wed, 9 Sep 2009 22:35:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Not really helpful with the original question, unfortunately.

Xilinx MIG (memory interface generator) hides I/Os deep in the design
hierarchy.
Too bad I don't have access to the code to see what the proper syntax
is.

"System level simulation won't be possible as the IOs are not
accessible"
Sorry to correct you here, but attaching SDRAM simulation models to
dedicated internal controller blocks is even easier than to the top
level.

Finally, making the design internal makes it much more portable, as
you can simply pass the controller interface with instantiated I/O
buffers and I/O to one of your engineers, and they never have to do
anything but work with the interface.

BTW, Xilinx realized recently that this is much more advantageous from
hardware standpoint than the ancient top level driven designs: the
latest ISE 10 allows multiple .ucf files for this reason.




Article: 142954
Subject: Re: Traversing hierarchy in UCF works for OBUF, but not IOBUF, please
From: Telenochek <elet.mirror@gmail.com>
Date: Wed, 9 Sep 2009 22:35:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
Not really helpful with the original question, unfortunately.

Xilinx MIG (memory interface generator) hides I/Os deep in the design
hierarchy.
Too bad I don't have access to the code to see what the proper syntax
is.

"System level simulation won't be possible as the IOs are not
accessible"
Sorry to correct you here, but attaching SDRAM simulation models to
dedicated internal controller blocks is even easier than to the top
level.

Finally, making the design internal makes it much more portable, as
you can simply pass the controller interface with instantiated I/O
buffers and I/O to one of your engineers, and they never have to do
anything but work with the interface.

BTW, Xilinx realized recently that this is much more advantageous from
hardware standpoint than the ancient top level driven designs: the
latest ISE 10 allows multiple .ucf files for this reason.




Article: 142955
Subject: Re: Traversing hierarchy in UCF works for OBUF, but not IOBUF, please
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 9 Sep 2009 23:09:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 9, 10:35=A0pm, Telenochek <elet.mir...@gmail.com> wrote:
> Not really helpful with the original question, unfortunately.
>
> Xilinx MIG (memory interface generator) hides I/Os deep in the design
> hierarchy.
> Too bad I don't have access to the code to see what the proper syntax
> is.
>
> "System level simulation won't be possible as the IOs are not
> accessible"
> Sorry to correct you here, but attaching SDRAM simulation models to
> dedicated internal controller blocks is even easier than to the top
> level.
>
> Finally, making the design internal makes it much more portable, as
> you can simply pass the controller interface with instantiated I/O
> buffers and I/O to one of your engineers, and they never have to do
> anything but work with the interface.
>
> BTW, Xilinx realized recently that this is much more advantageous from
> hardware standpoint than the ancient top level driven designs: the
> latest ISE 10 allows multiple .ucf files for this reason.

Actually, I think that the suggestion to bring the IO ports to the top
level is helpful to your orginal question as it appears that the net
name on the IO port of the IOBUF is different than you expected it to
be and this would solve the problem.

One addition suggestion, since you don't want to propogate the signal
then try adding the LOC to the instance name which likely has not
changed.

INST "eight_chan_gen/u1/external_sdram/U1/IOBUF_inst0"   LOC =3D "A4";

With respect to your comments on the MIG output, the physical level
interface is presented on the core interface with the intent that nets
are connected to the top level ports in the design.  This is shown in
all of the design examples.

I have no idea how "attaching SDRAM simulation models to the dedicated
internal memory blocks" is easier.   Please elaborate on why this is
easier to use and maintain between simulation and synthesis.

Ed McGettigan
--
Xilinx Inc.

Article: 142956
Subject: Re: ANN: Coding style guidance for FPGA memory
From: "colin_toogood@yahoo.com" <colin_toogood@yahoo.com>
Date: Thu, 10 Sep 2009 01:10:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Sep, 17:48, DJ Delorie <d...@delorie.com> wrote:
> Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> writes:
> > We ask for registration,
>
> Er, your privacy policy says you can spam us and change your policy at
> any time. =A0Can we get something a little more user-friendly than that?

Ah, now I remember why I have several trashable gmail and yahoo
accounts.
Is my name Colin?... sometimes it's hard to remember.

Article: 142957
Subject: Re: Traversing hierarchy in UCF works for OBUF, but not IOBUF, please help
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 10 Sep 2009 10:39:10 +0100
Links: << >>  << T >>  << A >>
On Wed, 9 Sep 2009 23:09:58 -0700 (PDT), Ed McGettigan
<ed.mcgettigan@xilinx.com> wrote:

>On Sep 9, 10:35 pm, Telenochek <elet.mir...@gmail.com> wrote:
>> Not really helpful with the original question, unfortunately.
>>
>> Xilinx MIG (memory interface generator) hides I/Os deep in the design
>> hierarchy.
>> Too bad I don't have access to the code to see what the proper syntax
>> is.
>>
>> "System level simulation won't be possible as the IOs are not
>> accessible"
>> Sorry to correct you here, but attaching SDRAM simulation models to
>> dedicated internal controller blocks is even easier than to the top
>> level.

>I have no idea how "attaching SDRAM simulation models to the dedicated
>internal memory blocks" is easier.   Please elaborate on why this is
>easier to use and maintain between simulation and synthesis.

I haven't done this; I confess I hadn't thought of it (being blinded by starting
from the Xilinx examples) but I can see how it would work...

You create a DDR block, e.g. a wrapper covering (MIG, all external ports, the
logic you must add to make MIG usable, AND the sim models) and then test the
hell out of it (a testbench instantiates the whole block).

For synthesis, the IOBs are inserted as instantiated, and the sim models are not
(they are guarded by "translate" pragmas).

This whole block can be dropped into a user design without having to add
superfluous ports on the instantiating block; the top level block; every
hierarchical level in between; AND the testbench. 

That eliminates a huge maintenance task, e.g. when you later change the memory
size, you have to add address and BA bits to every level and the testbench too.
Oh and you used this subsystem in a couple of dozen designs, so you have to
update over a hundred files to let someone plug a bigger SODIMM into the ML505.

Better to keep the I/Os and the sim models in the instantiated block; and simply
drop that, whole, into a user design. Just solve the tool flow issues first...

For an even better example of the maintenance nightmare approach, take a look at
how I/O signals are routed in the insane PCIe endpoint example design, as
created by Coregen.

- Brian

Article: 142958
Subject: ieee.math_real-support in Synplify for Lattice
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Thu, 10 Sep 2009 11:42:34 +0200
Links: << >>  << T >>  << A >>
Hi *,

I'm trying to use functions from math_real to calculate some constants
in a VHDL package. In Precision and XST, this works fine.

When I try to synthesize it with the Synplify-version shipped with the
Lattice ispLever tools, it complains that the functions I want to use
are not declared (ironically, it does NOT complain that math_real is not
available when the corresponding "use"-statement is compiled).

I can't find any definitive statement on this in the documentation...
math_real is not listed in the table of "Predefined VHDL Libraries and
Packages", but they ship an encrypted version of the source in
$LATTICE_FOLDER/synpbase/lib/vhd. Adding this file to the synthesis
project only results in syntax errors, so this is useless.

Can't find any info on this on the Lattice website, either. Can't
register for Synplicity-support since for registration they want a site
ID, which I don't have, since the version I use was not bought from
Synopsys but shipped with the Lattice tools...

So, I suppose math_real is simply not supported at all by Synplify? Or
is this some restriction in the Lattice-release?

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).

Article: 142959
Subject: Re: ieee.math_real-support in Synplify for Lattice
From: Alan Fitch <alan.fitch@spamtrap.com>
Date: Thu, 10 Sep 2009 11:28:42 +0100
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
> Hi *,
> 
> I'm trying to use functions from math_real to calculate some constants
> in a VHDL package. In Precision and XST, this works fine.
> 
> When I try to synthesize it with the Synplify-version shipped with the
> Lattice ispLever tools, it complains that the functions I want to use
> are not declared (ironically, it does NOT complain that math_real is not
> available when the corresponding "use"-statement is compiled).
> 
> I can't find any definitive statement on this in the documentation...
> math_real is not listed in the table of "Predefined VHDL Libraries and
> Packages", but they ship an encrypted version of the source in
> $LATTICE_FOLDER/synpbase/lib/vhd. Adding this file to the synthesis
> project only results in syntax errors, so this is useless.
> 
> Can't find any info on this on the Lattice website, either. Can't
> register for Synplicity-support since for registration they want a site
> ID, which I don't have, since the version I use was not bought from
> Synopsys but shipped with the Lattice tools...
> 

For your information, Synopsys Solvnet does state that synplify supports
math_real. The article refers to "synplify, synplify_pro" and is dated 
25/01/2007.

But maybe that doesn't apply to OEM versions of synplify - it doesn't say.

regards
Alan

> So, I suppose math_real is simply not supported at all by Synplify? Or
> is this some restriction in the Lattice-release?
> 
> cu,
> Sean
> 



-- 
Alan Fitch
Senior Consultant

Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 
1AW, UK
Tel:  + 44 (0)1425 471223		Email: alan.fitch@doulos.com	
Fax:  +44 (0)1425 471573		http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of 
Doulos, unless specifically stated.

Article: 142960
Subject: Re: ieee.math_real-support in Synplify for Lattice
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Thu, 10 Sep 2009 12:56:17 +0200
Links: << >>  << T >>  << A >>
Hi Alan,

Alan Fitch wrote:
> For your information, Synopsys Solvnet does state that synplify supports
> math_real. The article refers to "synplify, synplify_pro" and is dated
> 25/01/2007.
> 
> But maybe that doesn't apply to OEM versions of synplify - it doesn't say.
thanks for the info. I'll have to contact Lattice and ask them, I
suppose... And in the meantime work around the problem...

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).

Article: 142961
Subject: Re: UART testbench debug
From: "jaimico" <p_jaime7@hotmail.com>
Date: Thu, 10 Sep 2009 06:02:30 -0500
Links: << >>  << T >>  << A >>
Hi
try to send the value in HEX, I had the same problem trying sending ASCII
but it not work

constant dato1 : std_logic_vector(7 downto 0) := X"44";--VHDL code,
transmit a D out the UART RS232

JP



Article: 142962
Subject: Re: UART testbench debug
From: johnp <jprovidenza@yahoo.com>
Date: Thu, 10 Sep 2009 07:15:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 10, 4:02=A0am, "jaimico" <p_jai...@hotmail.com> wrote:
> Hi
> try to send the value in HEX, I had the same problem trying sending ASCII
> but it not work
>
> constant dato1 : std_logic_vector(7 downto 0) :=3D X"44";--VHDL code,
> transmit a D out the UART RS232
>
> JP

Do you have a `timescale directive appropriately placed?  Are you sure
you're in ns?
You probably want something like  `timescale 1 ns / 10 ps

John Providenza

Article: 142963
Subject: Re: ieee.math_real-support in Synplify for Lattice
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Thu, 10 Sep 2009 16:47:34 +0200
Links: << >>  << T >>  << A >>
Sean Durkin schrieb:
> Hi *,
> 
> I'm trying to use functions from math_real to calculate some constants
> in a VHDL package. In Precision and XST, this works fine.
> 
> When I try to synthesize it with the Synplify-version shipped with the
> Lattice ispLever tools, it complains that the functions I want to use
> are not declared (ironically, it does NOT complain that math_real is not
> available when the corresponding "use"-statement is compiled).
> 
> I can't find any definitive statement on this in the documentation...
> math_real is not listed in the table of "Predefined VHDL Libraries and
> Packages", but they ship an encrypted version of the source in
> $LATTICE_FOLDER/synpbase/lib/vhd. Adding this file to the synthesis
> project only results in syntax errors, so this is useless.
> 
> Can't find any info on this on the Lattice website, either. Can't
> register for Synplicity-support since for registration they want a site
> ID, which I don't have, since the version I use was not bought from
> Synopsys but shipped with the Lattice tools...
> 
> So, I suppose math_real is simply not supported at all by Synplify? Or
> is this some restriction in the Lattice-release?

In case anyone's interested: It works fine if you start Synplify
stand-alone, not through the ispLever project navigator. I guess
ispLever adjusts the path where Synplify is looking for its pre-compiled
libraries to somewhere where libs with Lattice-cores are available but
not math_real...

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).

Article: 142964
Subject: An email from Altera
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Thu, 10 Sep 2009 15:27:42 GMT
Links: << >>  << T >>  << A >>
Got an email from Altera.
It pointed me to a movie clip.
The movie clip shows a sales manager ? and application engineer explaining
the latest and greatest high speed development board (think it was).
No problem so far, except that both these persons speak what can perhaps
best be described as 'Indian or Pakistani English'.
Very very hard to make it out, had to stop that video and let sink in what they were on about.

Is that the new US standard pronunciation?
Or is the market far east anyways an there they all speak like that?

How about giving at least your sales rep a tutorial on how to
pronounce US English (or UK English)?
Is this the new trend?


Article: 142965
Subject: Re: An email from Altera
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Thu, 10 Sep 2009 08:33:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 10, 6:27=A0pm, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote:
> Got an email from Altera.
> It pointed me to a movie clip.
> The movie clip shows a sales manager ? and application engineer explainin=
g
> the latest and greatest high speed development board (think it was).
> No problem so far, except that both these persons speak what can perhaps
> best be described as 'Indian or Pakistani English'.
> Very very hard to make it out, had to stop that video and let sink in wha=
t they were on about.
>
> Is that the new US standard pronunciation?
> Or is the market far east anyways an there they all speak like that?
>
> How about giving at least your sales rep a tutorial on how to
> pronounce US English (or UK English)?
> Is this the new trend?

yes, it is

Article: 142966
Subject: Re: An email from Altera
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 10 Sep 2009 17:18:33 +0100
Links: << >>  << T >>  << A >>
This is just a ploy to get us to go and watch the video that we
didn't bother watching first time round.

Isn't it?


Nial. 



Article: 142967
Subject: Re: Bidirectional Bus
From: nobody <cydrollinger@gmail.com>
Date: Thu, 10 Sep 2009 13:36:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Completion,

The FPGA never releases  the Global Three State(GTS) after done goes
high, described in DS312 pg. 107, because the fpga_cclk shuts down one
clock cycle to early. After the revision of taking out the need to
program while FPGA_initb is high gives the extra fpga_cclk needed to
release GTS signal and drives the High Z FPGA_d bus. One stinking
clock cycle who knew?

Sincerely,

Cy Drollinger


Article: 142968
Subject: Re: Bidirectional Bus
From: gabor <gabor@alacron.com>
Date: Thu, 10 Sep 2009 15:34:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 10, 4:36=A0pm, nobody <cydrollin...@gmail.com> wrote:
> Completion,
>
> The FPGA never releases =A0the Global Three State(GTS) after done goes
> high, described in DS312 pg. 107, because the fpga_cclk shuts down one
> clock cycle to early. After the revision of taking out the need to
> program while FPGA_initb is high gives the extra fpga_cclk needed to
> release GTS signal and drives the High Z FPGA_d bus. One stinking
> clock cycle who knew?
>
> Sincerely,
>
> Cy Drollinger

You can change the order of the startup events in the bitgen
options.  I've have similar problems when using a micro to
load the FPGA and stopping as soon as DONE is high.  The
default startup sequence sets DONE high before releasing
GSR.  For a design with only one FPGA this is not necessary.
The intent is to synchronize startup of multiple devices
in a chain.

Regards,
Gabor

Article: 142969
Subject: Re: An email from Altera
From: "Martin Riddle" <martin_rid@verizon.net>
Date: Thu, 10 Sep 2009 19:07:54 -0400
Links: << >>  << T >>  << A >>


"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message 
news:h8b5tj$jc2$1@news.albasani.net...
> Got an email from Altera.
> It pointed me to a movie clip.
> The movie clip shows a sales manager ? and application engineer 
> explaining
> the latest and greatest high speed development board (think it was).
> No problem so far, except that both these persons speak what can 
> perhaps
> best be described as 'Indian or Pakistani English'.
> Very very hard to make it out, had to stop that video and let sink in 
> what they were on about.
>
> Is that the new US standard pronunciation?
> Or is the market far east anyways an there they all speak like that?
>
> How about giving at least your sales rep a tutorial on how to
> pronounce US English (or UK English)?
> Is this the new trend?
>

Hope not. I can't understand them either.
Just wish they fix their password reset feature on their web site.

Cheers
 



Article: 142970
Subject: Re: Bidirectional Bus
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Thu, 10 Sep 2009 23:17:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 10, 11:36=A0pm, nobody <cydrollin...@gmail.com> wrote:
> Completion,
>
> The FPGA never releases =A0the Global Three State(GTS) after done goes
> high, described in DS312 pg. 107, because the fpga_cclk shuts down one
> clock cycle to early. After the revision of taking out the need to
> program while FPGA_initb is high gives the extra fpga_cclk needed to
> release GTS signal and drives the High Z FPGA_d bus. One stinking
> clock cycle who knew?
>
> Sincerely,
>
> Cy Drollinger

Cy

this was actually OBVIOUS, I assumed you KNOW FPGA is configured AND
working
(this is not same as done=3D1)

it is always wise to send extra clocks after done=3D1... this is for me
common knowledge
i should have suggested this earlier, but i assumed you DID know that
FPGA was
actually driving the pins

btw bus conflict and non-driving bus can be seen as different with DSO
or even multimeter

Antti




Article: 142971
Subject: Behavior of crystal oscillator?
From: "sdaau" <sd@imi.aau.dk>
Date: Fri, 11 Sep 2009 04:24:10 -0500
Links: << >>  << T >>  << A >>
Dear list, 

I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal oscillator,
DIP-8 package: 

http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0
(datasheet
http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf)

But something about its behaviours puzzles me: To start with, the
datasheet says: "Supply Voltage: 5V ±0.25V".

I have hooked this crystal to a lab power supply, where I can change the
supply voltage, and I start slowly increasing the voltage. From 0, up to
until about 2.6V power supply, the oscillator behaves as I expect - that
is, the output is from about 10% to about 90% of supply voltage, as per
datasheet: 

http://img222.imageshack.us/img222/1258/xooscmeas01.jpg

(excuse the poor quality, I cannot focus the camera any better. The line
from channel 2 is used to indicate the zero. This scope cannot resolve 50
Mhz, so I'm just using the shaded area as indication of oscillations)

However, as soon as I cross 2.6V power supply, the working regime sort of
flips - and apparently there are some oscillations, but from roughly 70% to
90% of power supply - for instance, here is how it looks for the 5V supply
(as per datasheet)  

http://img222.imageshack.us/img222/5435/xooscmeas02.jpg

My questions are: 
* Is this the expected behavior of this crystal oscillator - or is this
maybe a damaged part? 
* Since this was just the oscillator connected directly to power supply
(no capacitors or anything as per "Test Circuit" in the datasheet), should
I maybe expect that external components would make a difference (in the
sense of allowing output of about 10% to about 90% of supply voltage, even
for 5V supply?) 
* If this is the expected behavior for this part - can I take that most
crystal oscillators on the market will show similar behaviour? 

Thanks for any comments, 
Cheers!
	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 142972
Subject: Re: Does ModelSim or any simulator software have a function similar
From: ehliar@isy.liu.se
Date: Fri, 11 Sep 2009 05:03:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 Aug, 01:41, Weng Tianxiang <wtx...@gmail.com> wrote:
> I have a project continuously running more than 20 days to get an
> error. In my project I have many assert statements to make sure the
> design is going well. If there is an error, the design stops.
>
> But I couldn't open the waveform window under ModelSim when starting
> the simulation, the reason is very simple: any size of hard disk would
> be filled up within one day simulation.

I've been in almost the same situation and I have also managed to
crash
our fileserver by creating a logfile that was too large... :)

My solution was to use checkpoints in modelsim.

1. Compile all source code files with +acc so that it is possible to
add
   signals to the wave window.
2. Run simulation for 1 hour or until an error occurs.
3. If no error occured, save a checkpoint with a unique serial number,
go back to step 2
4. At this point you can load up the latest checkpoint, add all
relevant signals to your wave
   window (or signal log if you like the log-command) and rerun the
simulation

The advantage of this approach is that you don't have to spend any
computation
time to log signal changes while retaining the ability to have full
visibility
when you are actually close to an error.


Look for the checkpoint command in the Modelsim documentation for more
info.

/Andreas

Article: 142973
Subject: Re: Behavior of crystal oscillator?
From: "Phil Jessop" <phil@noname.org>
Date: Fri, 11 Sep 2009 13:24:56 +0100
Links: << >>  << T >>  << A >>

"sdaau" <sd@imi.aau.dk> wrote in message 
news:_eKdnbazo6OnijfXnZ2dnUVZ_rCdnZ2d@giganews.com...
> Dear list,
>
> I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal oscillator,
> DIP-8 package:
>
> http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0
> (datasheet
> http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf)
>
> But something about its behaviours puzzles me: To start with, the
> datasheet says: "Supply Voltage: 5V ±0.25V".
>
> I have hooked this crystal to a lab power supply, where I can change the
> supply voltage, and I start slowly increasing the voltage. From 0, up to
> until about 2.6V power supply, the oscillator behaves as I expect - that
> is, the output is from about 10% to about 90% of supply voltage, as per
> datasheet:
>
> http://img222.imageshack.us/img222/1258/xooscmeas01.jpg
>
> (excuse the poor quality, I cannot focus the camera any better. The line
> from channel 2 is used to indicate the zero. This scope cannot resolve 50
> Mhz, so I'm just using the shaded area as indication of oscillations)
>
> However, as soon as I cross 2.6V power supply, the working regime sort of
> flips - and apparently there are some oscillations, but from roughly 70% 
> to
> 90% of power supply - for instance, here is how it looks for the 5V supply
> (as per datasheet)
>
> http://img222.imageshack.us/img222/5435/xooscmeas02.jpg
>
> My questions are:
> * Is this the expected behavior of this crystal oscillator - or is this
> maybe a damaged part?
> * Since this was just the oscillator connected directly to power supply
> (no capacitors or anything as per "Test Circuit" in the datasheet), should
> I maybe expect that external components would make a difference (in the
> sense of allowing output of about 10% to about 90% of supply voltage, even
> for 5V supply?)
> * If this is the expected behavior for this part - can I take that most
> crystal oscillators on the market will show similar behaviour?
>
> Thanks for any comments,
> Cheers!
>
>

...datasheet says: "Supply Voltage: 5V ±0.25V".

All other bets are off.





Article: 142974
Subject: Re: Behavior of crystal oscillator?
From: "Fredxx" <fredxx@spam.com>
Date: Fri, 11 Sep 2009 14:25:13 +0100
Links: << >>  << T >>  << A >>
Phil Jessop wrote:
> "sdaau" <sd@imi.aau.dk> wrote in message
> news:_eKdnbazo6OnijfXnZ2dnUVZ_rCdnZ2d@giganews.com...
>> Dear list,
>>
>> I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal
>> oscillator, DIP-8 package:
>>
>> http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0
>> (datasheet
>> http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf)
>>
>> But something about its behaviours puzzles me: To start with, the
>> datasheet says: "Supply Voltage: 5V ±0.25V".
>>
>> I have hooked this crystal to a lab power supply, where I can change
>> the supply voltage, and I start slowly increasing the voltage. From
>> 0, up to until about 2.6V power supply, the oscillator behaves as I
>> expect - that is, the output is from about 10% to about 90% of
>> supply voltage, as per datasheet:
>>
>> http://img222.imageshack.us/img222/1258/xooscmeas01.jpg
>>
>> (excuse the poor quality, I cannot focus the camera any better. The
>> line from channel 2 is used to indicate the zero. This scope cannot
>> resolve 50 Mhz, so I'm just using the shaded area as indication of
>> oscillations) However, as soon as I cross 2.6V power supply, the working 
>> regime
>> sort of flips - and apparently there are some oscillations, but from
>> roughly 70% to
>> 90% of power supply - for instance, here is how it looks for the 5V
>> supply (as per datasheet)
>>
>> http://img222.imageshack.us/img222/5435/xooscmeas02.jpg
>>
>> My questions are:
>> * Is this the expected behavior of this crystal oscillator - or is
>> this maybe a damaged part?
>> * Since this was just the oscillator connected directly to power
>> supply (no capacitors or anything as per "Test Circuit" in the
>> datasheet), should I maybe expect that external components would
>> make a difference (in the sense of allowing output of about 10% to
>> about 90% of supply voltage, even for 5V supply?)
>> * If this is the expected behavior for this part - can I take that
>> most crystal oscillators on the market will show similar behaviour?
>>
>> Thanks for any comments,
>> Cheers!
>>
>>
>
> ...datasheet says: "Supply Voltage: 5V ±0.25V".
>
> All other bets are off.

My thoughts, and as the OP has suggested all's well at 90% of 5V, that the 
device is behaving as expected.

I would expect a working range to be a little wider than specified range as 
indeed the OP experiences.





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