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 57150

Article: 57150
Subject: Re: FPGA GPU (Spartan IIe 300K)
From: "Morten Leikvoll" <mleikvol@online.nospam>
Date: Tue, 24 Jun 2003 18:25:49 +0200
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> skrev i melding
news:bcpa5r$kphfi$1@ID-84877.news.dfncis.de...
>
> "Bazaillion" <nospam@nospam.org> schrieb im Newsbeitrag
> news:kjcvevsik67eb2nhs2vdkl4bbgi1084gm3@4ax.com...
> > I forgot to add "With exteral Ram for the Video."
>
> www.fpgaarcade.com
>
> I rebuilded these pacman with a 200k Spartan-II. What it needs are two
> external FLASH memories for program and character storage. But if you have
> plenty of BRAMS, you can integrate at least on of the two ROMs.
> You also need some small adaptors for VGA, audio and joystick. But this is
> just some bell wire on a breadboard.

I wonder if someone would be so kind to discretely mail the rom-files for
these games to me if I post this request here ;D
(remove the word spam from my mail adress)




Article: 57151
Subject: Re: regarding I2C protocols
From: CBFalconer <cbfalconer@yahoo.com>
Date: Tue, 24 Jun 2003 16:41:05 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
> y_p_w wrote:
> >
> > Well - here's my concerns and thinking:
> >
> > 1) It seems that the preferred method is to have a STOP condition
> >    (SDA rising when SCL=1) on the same SCL high period as a START
> >    period (SDA falling when SCL=1).  This would look like this:
> >             _________________________
> >    SCL  ___|                         |_____
> >                 _________________
> >    SDA  _______|                 |_________
> >
> > 2) As far as I can tell the spec says nothing about SCL changing
> >    between a STOP and START.  I wouldn't see any advantage to it,
> >    but I couldn't sense it was illegal.  I would suppose any
> >    clock toggling before a START should just be ignored until a
> >    START is detected.
> >
> > 3) I was worried about whether a master could "change its mind"
> >    after issuing a start if it was suddenly occupied with something
> >    considered more important.  Fortunately, this doesn't seem to
> >    be a problem.
> >
> > 4) Most of what I'm planning is a straightforward FSM clocked on
> >    the negedge of SCL.  The START and STOP logic I'm planning on
> >    using isn't as straightforward.  This was the part that would
> >    have been messed up if I had to account for multiple START or
> >    STOP methods.  I wanted to create a START detected signal, and
> >    use that to tell the FSM when to start monitoring SDA.
> >
> > 5) I could possibly use a high-speed internal clock.  However -
> >    the goal is a low-power design, and I was told that just
> >    toggling the clock tree would create unnecessary power
> >    consumption.
> 
> I have not given this a lot of thought, but I believe you can use two
> FFs (with resets) to detect the start/stop conditions and maintain a
> state of disabled/enabled.
> 
> The start FF is clocked on the falling edge of SDA with SCL on the D
> input.  This FF will be set on a start condition.  The stop FF will
> be clocked on the rising edge of SDA with SCL on the D input.  This
> FF will be set on the stop condition.  The start FF being off will
> hold the stop FF in reset.  The stop FF being set will reset the
> start FF.  So the sequence will be;
> 
> 1) both FFs clear
> 2) on start, the start FF is set and the rest of the circuit is enabled
> 3) on stop, the stop FF is set which clears the start FF
> 4) the start FF being cleared also clears the stop FF
> 
> The only issue I can see with this design is that the stop FF will
> generate a reset pulse determined by the time it takes to reset both
> FFs plus the routing.  Some people would object to this saying it may
> violate the timing requirements of your logic.  If so, you may want to
> use the LUT or the OR array with the FF to add some extra delay.  In
> general this should work ok since it is basically self timed logic.
> 
> On the other hand, using a synchronous design should not consume much
> power.  Unless you are going for power below 100 uA, a low power CPLD
> (like the coolrunner) should be able to run at 1 MHz (fast enough for
> most I2C chips at 400 kb/s) with power at that level.

I know nothing about the actual details of this protocol, but it
seems to me that something is off the rails.  Just the signal
names suggest SerialData and SerialClock.  Some edge of SCL must
capture the state of SDA.  The above protocol suggests that SDA
can only change while SCL is high,  However that conflicts with
the idea that particular transitions on SDA during SCL high are of
special significance, such as message framing.

I seem to vaguely recall that I2C is a collision detection and
backoff system with priority determined by addresses, operating at
baseband.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!



Article: 57152
Subject: Re: How to get 27MHz from 10 MHz in FPGA???
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 24 Jun 2003 09:43:11 -0700
Links: << >>  << T >>  << A >>
Good question, and you gave the right answer yourself:
In frequency synthesis the incoming frequency is multiplied by M/D, and
only the output frequency must be >24 MHz.
Good catch...
Peter
============================
Alvin Andries wrote:

> What about the minimal 24 MHz clock frequency for the DCM or does it only
> apply to the output clock frequency?
> 
> Regards,
> Alvin Andries.

Article: 57153
Subject: Re: regarding I2C protocols
From: "Tauno Voipio" <tauno.voipio@iki.fi.SPAMBAIT_REMOVE.invalid>
Date: Tue, 24 Jun 2003 16:52:59 GMT
Links: << >>  << T >>  << A >>

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:3EF87139.36651031@yahoo.com...
(-- most clipped, TV --)

>
> I know nothing about the actual details of this protocol, but it
> seems to me that something is off the rails.  Just the signal
> names suggest SerialData and SerialClock.  Some edge of SCL must
> capture the state of SDA.  The above protocol suggests that SDA
> can only change while SCL is high,  However that conflicts with
> the idea that particular transitions on SDA during SCL high are of
> special significance, such as message framing.

In actual data transmission it's not allowed to change the data when the
clock is high. The start and stop conditions are distinguished from normal
data bits by breaking the data transfer protocol here.

> I seem to vaguely recall that I2C is a collision detection and
> backoff system with priority determined by addresses, operating at
> baseband.

Yes - the contention is taken care by the open-drain/collector nature of the
bus. The master seeing its output clamped down by another master has to
backoff.

There is a similar method to synchronise the clocks: any station feeling
that the things are going too fast is allowed to extend the clock-down time
by clamping it. The sending station has to honour the clock clamp and wait.

HTH

Tauno Voipio
tauno voipio @ iki fi



Article: 57154
Subject: Re: How to get 27MHz from 10 MHz in FPGA???
From: brad@tinyboot.com (Brad Eckert)
Date: 24 Jun 2003 10:02:11 -0700
Links: << >>  << T >>  << A >>
lelik_bolik@hotbox.ru (Lelik Bolik) wrote in message news:<d9c9b7aa.0306232336.bbd6bd7@posting.google.com>...
> I have stable 10 MHz. Is it possible to get 27 MHz from this frequency
> using FPGA(Altera ACEX)?? And if it is then how?? Thanks for your
> answers!

If a constant period is not important, multiply by 4 with a PLL and
multiply by 27/40 with a counter. The counter would remove almost
every other cycle of the 40 MHz.

I think the ACEX has only one ClockBoost circuit and it multiplies by
two so you can only get 20 MHz. If so, maybe you could use a time
delay and XOR to get the 40 MHz clock. Time delays aren't a safe thing
to design in, but if you think the chips won't change too much then do
what you have to do.

Article: 57155
Subject: Re: regarding I2C protocols
From: y_p_w@hotmail.com (y_p_w)
Date: 24 Jun 2003 10:41:51 -0700
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3EF86106.BCB1DCB@yahoo.com>...
> y_p_w wrote:
> > 
> > Well - here's my concerns and thinking:
> > 
> > 1) It seems that the preferred method is to have a STOP condition
> >    (SDA rising when SCL=1) on the same SCL high period as a START
> >    period (SDA falling when SCL=1).  This would look like this:
> >             _________________________
> >    SCL  ___|                         |_____
> >                 _________________
> >    SDA  _______|                 |_________
> > 
> > 2) As far as I can tell the spec says nothing about SCL changing
> >    between a STOP and START.  I wouldn't see any advantage to it,
> >    but I couldn't sense it was illegal.  I would suppose any
> >    clock toggling before a START should just be ignored until a
> >    START is detected.
> > 
> > 3) I was worried about whether a master could "change its mind"
> >    after issuing a start if it was suddenly occupied with something
> >    considered more important.  Fortunately, this doesn't seem to
> >    be a problem.
> > 
> > 4) Most of what I'm planning is a straightforward FSM clocked on
> >    the negedge of SCL.  The START and STOP logic I'm planning on
> >    using isn't as straightforward.  This was the part that would
> >    have been messed up if I had to account for multiple START or
> >    STOP methods.  I wanted to create a START detected signal, and
> >    use that to tell the FSM when to start monitoring SDA.
> > 
> > 5) I could possibly use a high-speed internal clock.  However -
> >    the goal is a low-power design, and I was told that just
> >    toggling the clock tree would create unnecessary power
> >    consumption.
> 
> I have not given this a lot of thought, but I believe you can use two
> FFs (with resets) to detect the start/stop conditions and maintain a
> state of disabled/enabled.  
> 
> The start FF is clocked on the falling edge of SDA with SCL on the D
> input.  This FF will be set on a start condition.  The stop FF will be
> clocked on the rising edge of SDA with SCL on the D input.  This FF will
> be set on the stop condition.  The start FF being off will hold the stop
> FF in reset.  The stop FF being set will reset the start FF.  So the
> sequence will be; 
> 
> 1) both FFs clear
> 2) on start, the start FF is set and the rest of the circuit is enabled
> 3) on stop, the stop FF is set which clears the start FF 
> 4) the start FF being cleared also clears the stop FF

I had something a little different, but not far off from your suggestion.
Think masking off one signal with the other.

> The only issue I can see with this design is that the stop FF will
> generate a reset pulse determined by the time it takes to reset both FFs
> plus the routing.  Some people would object to this saying it may
> violate the timing requirements of your logic.  If so, you may want to
> use the LUT or the OR array with the FF to add some extra delay.  In
> general this should work ok since it is basically self timed logic.  
> 
> On the other hand, using a synchronous design should not consume much
> power.  Unless you are going for power below 100 uA, a low power CPLD
> (like the coolrunner) should be able to run at 1 MHz (fast enough for
> most I2C chips at 400 kb/s) with power at that level.  

I won't go into the proprietary details, but I'm doing this work for an
SoC design that might be battery powered in some applications. My boss
is keen on reducing power consumption during a standby mode.

I also apologize if I don't get into specifics about my planned design
that might explain my problems.  As with many in these NG's, I work at
a large company that considers the product I produce confidential.  If
this works well, I (personally) wouldn't be averse to submitting this
as an open source Verilog block.  However - I'd have to make sure this
is OK with my employer.

Yu-Ping Wang
Berkeley, California

Article: 57156
Subject: Re: defective netlist in ISE 5.2.03
From: "Richard Erlacher" <richard_no_junk_mail@idcomm.com>
Date: Tue, 24 Jun 2003 13:21:41 -0600
Links: << >>  << T >>  << A >>
This was, in fact, a case of pilot error.  I had a mismatch at an upper
layer of the hierarchy, between the wiring of the various module outputs,
and, when one of the modules was changed, I failed to note the change in
signal definitions.  <sigh>  It does help to have someone else look at one's
work.  Someone outside the project spotted my error right away.

Richard Erlacher

"Richard Erlacher" <richard_no_junk_mail_4_me @idcomm.com> wrote in message
news:3ef0f007$1@mindmeld.idcomm.com...
> I've found that ISE v5.2.03 is apparently producing an erroneous netlist
for
> a 4-bit shift register.  This happens both for a discretly implemented
one,
> using the FD (no enable, preset, or clear) or the SR4CE library element,
> with its enable hooked to Vcc and its clear stroked once at the outset of
> the testbench.
>
> It shows evidence of an erroneous netlist both in the fitter report and in
> the simulation waveform.  Is there a way of finding out why this is
> occurring and of fixing it?
>
> thanks,
>
>
> -- 
> regards,
>
> Richard Erlacher
> Principal Engineer
> id Communications
>
>



Article: 57157
Subject: Re: Quartus II - Acex1k - Routing resources
From: Rene Tschaggelar <tschaggelar@dplanet.ch>
Date: Tue, 24 Jun 2003 19:30:29 GMT
Links: << >>  << T >>  << A >>
GC wrote:
> Hi all,
> I have the following problem compiling my project with Quartus II on
> EP1K100QC208-3 (Acex 1K family): resources utilization is under limits
> (4537/4992 LEs, 34816/49152 mem bits, 84/147 pins) and if I remove all pin
> assignments the project compiles properly. When I set pin assignments the
> compilation process can not end successfully, with several error messages
> like this: "Can't route source node ....".
> I don't know how I can solve this problem.
> Any suggestion would be highly appreciated.

There are several options to be checked to get the full
routing possibilities. I wouldn't know them off memory.
You already have the pcb made and therefore cannot
reassign pins for a better routing, haven't you ?

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


Article: 57158
Subject: Re: How to Capture a VGA display EXTERNALLY
From: benn686@hotmail.com (Ben Nguyen)
Date: 24 Jun 2003 13:55:55 -0700
Links: << >>  << T >>  << A >>
Ralph, 

I found an open source core that will take RGB input and output NTSC/PAL video.
My only problem is that I cant make much sense out of the documentation.

My FPGA currently outputs VGA (640x480@60hz) to a DAC using only:
Red, Green, Blue, Horizontal and Vertical Sync.  

The ntsc module takes RGB (format? rate?) and generates:
CVBS DAC Data, Composite and vertical sync

I figure I would drive the CVBS signal to the "green" channel, but how does
the composite Sync fit into the picture?  Would it be wired to the vertical 
sync line? 

Just looking to capture my video data from a standalone board to a TV.
http://www.opencores.org/projects/lite_videocoder/


Thanks!









> 
> Being that this is a FPGA group, I would suggest a FPGA and 3 dacs.
> 
> Ralph

Article: 57159
Subject: Re: applying SCHMITT_TRIGGER to CoolRunner-II CPLD's
From: "Richard Erlacher" <richard_no_junk_mail@idcomm.com>
Date: Tue, 24 Jun 2003 14:58:24 -0600
Links: << >>  << T >>  << A >>


Yes ... that's the sort of issue that it was ... since I'd put 
together a number of independently defined modules in schematic 
form.  The trick, if you want to call it that, is to keep the 
SCHMITT_TRIGGER attribute on the topmost level only.  The 
software doesn't know to move it to the uppermost level 
automatically, nor could it.  

What I'd done in this case was to create a circuit that 
produced a stimulus for the rest of the device, thereby 
enabling me to simulate the circuit and, ultimately, to 
test and verify the hardware.  However, what I didn't 
know was that I had to move the ports to the uppermost block 
diagram in order to keep from persuading the software that 
I wanted internal schmitts, which it doesn't do.  

Thanks for the comment.

Richard Erlacher
  <Arthur> wrote in message news:ee7e175.0@WebX.sUN8CHnE...
  Is this a schematic design? Check the fitter report to see 
  if sw1_ibuf is the top level port name. I suspect that 
  sw1_ibuf may be the name that you applied to the net 
  driven by the IBUF in the design. Name the net between 
  the pad and the input of the IBUF and use that for your 
  Schmitt trigger constraint.
  
  
  



Article: 57160
Subject: Re: PALs, GALs and ABEL
From: "Richard Erlacher" <richard_no_junk_mail@idcomm.com>
Date: Tue, 24 Jun 2003 15:04:39 -0600
Links: << >>  << T >>  << A >>
The Lattice web site no longer has the Palasm 4 v1.5 disk set out there
where you can readily get at it.  Translating to Palasm might be a little
more work than going the other direction, but if your designs are in 'L'
parts, unless you've used combinatorial-lop latches and other twisted
constructs like that, you should have no trouble generating compatible
equations from the ABEL sources in order to create useable jedec files for
programming the newer parts.  with the cases you've mentioned you should
have no problems with product term depletion or any other resource
allocation issue, and the 20V8 and 22V10 both can replace the 'L' parts you
meniton.

-- 
Richard Erlacher
Principal Engineer
id Communications
303 790-4343

"Paul Urbanus" <urbpublic@hotmail.com> wrote in message
news:3EF31484.8060904@hotmail.com...
> I have two old designs - from 1987 - that I wrote in ABEL (by Data I/O)
> that fit into a PAL20L8 and a PAL20L10. I want to program some new parts
> with these designs, but only have GAL20V8 and GAL22V10 parts available.
>
> According to a Lattice Semi data sheet, there parts are supposed to be
> fuse compatible with all of the parts they replace. So, in theory I
> should be able (pardon the pun) to use the PAL20L10 JEDEC file to
> program the GAL22V10 and the PAL20L8 JEDEC file to program the GAL20L8.
>
> Anyone have any experience in this matter who can say, "Yes, it will
> work, or, no way in Hades this will work?"
>
> On a related note, does anyone know if the old DOS version of ABEL is in
> the public domain? And if so, where I can download a new version.
>
> Of course, I could always recode the PALS in VHDL using the Cypress Warp
> software, which used to support the 22V10, at least.
>
> Thanx
>
>
> ______________________________________________________________________
> Posted Via Uncensored-News.Com - Still Only $9.95 -
http://www.uncensored-news.com
>       <><><><><><><>   The Worlds Uncensored News Source
<><><><><><><><>
>



Article: 57161
Subject: Xilinx EDK examples from Website
From: enliteneer@mindless.com (eric)
Date: 24 Jun 2003 14:11:42 -0700
Links: << >>  << T >>  << A >>
Does anyone know where I can purchase just the examples for the EDK?
http://www.xilinx.com/ise/embedded/edk_examples.htm

I contacted Xilinx but never received a response.  Perhaps they figure
it wouldnt be of much use without the EDK, but as a (financially) struggling
student I would say its better than nothing!

Thanks!

Article: 57162
Subject: Re: FPGA GPU (Spartan IIe 300K)
From: "MikeJ" <support@{nospam}fpgaarcade.com>
Date: Tue, 24 Jun 2003 22:13:03 +0100
Links: << >>  << T >>  << A >>
these chaps have also done a pacman implementation, with composite video
output  - I will add a link to the fpgaarcade website. I am going to get one
of my Japanese friends to translate it for me !

http://members.tripod.co.jp/x1resource/xilinx/fpgapac/index.htm

/Mike



Article: 57163
Subject: Re: FPGA GPU (Spartan IIe 300K)
From: "Morten Leikvoll" <mleikvol@online.nospam>
Date: Tue, 24 Jun 2003 23:26:49 +0200
Links: << >>  << T >>  << A >>
"MikeJ" <support@{nospam}fpgaarcade.com> wrote in message
news:1056488903.54859.0@ersa.uk.clara.net...
> these chaps have also done a pacman implementation, with composite video
> output  - I will add a link to the fpgaarcade website. I am going to get
one
> of my Japanese friends to translate it for me !
>
> http://members.tripod.co.jp/x1resource/xilinx/fpgapac/index.htm
>
> /Mike

No problem.. Just run it through babelfish :)

<http://babelfish.altavista.com/babelfish/tr?doit=done&urltext=http%3A%2F%2F
members.tripod.co.jp%2Fx1resource%2Fxilinx%2Ffpgapac%2Findex.htm&lp=ja_en>




Article: 57164
Subject: Re: FPGA GPU (Spartan IIe 300K)
From: "MikeJ" <support@{nospam}fpgaarcade.com>
Date: Tue, 24 Jun 2003 22:55:22 +0100
Links: << >>  << T >>  << A >>
> >
> > /Mike
>
> No problem.. Just run it through babelfish :)
>
>
<http://babelfish.altavista.com/babelfish/tr?doit=done&urltext=http%3A%2F%2F
> members.tripod.co.jp%2Fx1resource%2Fxilinx%2Ffpgapac%2Findex.htm&lp=ja_en>
>

surprisingly good actually, the Galaxian page comes out far more
entertaining !



Article: 57165
Subject: Re: regarding I2C protocols
From: "kryten_droid" <kryten_droid@ntlworld.com>
Date: Tue, 24 Jun 2003 23:09:40 +0100
Links: << >>  << T >>  << A >>
Opencores and Xilinx have VHDL I2C code that might be of use.
Though of course there is no warranty on its correctness.




Article: 57166
Subject: Re: How to Capture a VGA display EXTERNALLY
From: "kryten_droid" <kryten_droid@ntlworld.com>
Date: Tue, 24 Jun 2003 23:27:51 +0100
Links: << >>  << T >>  << A >>
"Ben Nguyen" <benn686@hotmail.com> wrote in message
news:e604be8.0306241255.2ed47034@posting.google.com...
> I found an open source core that will take RGB input and output NTSC/PAL
video.
> My only problem is that I cant make much sense out of the documentation.
>
> My FPGA currently outputs VGA (640x480@60hz) to a DAC using only:
> Red, Green, Blue, Horizontal and Vertical Sync.

I doubt that core will help you.

It doesn't buffer VGA lines then read them out in interlaced order and at
half speed, which is what you'd need to squash VGA into NTSC or PAL.

It only converts the colour signals from RGB to CVBS.

And even that isn't worth using 50K gates when you can by ready-made chips
to do the same job cheaply.
(AD722, AD724, AD725, CXA1645P, CXA2075M, TDA8501). RS Components sell only
the Sony CXA1645P for £6.13+VAT.





Article: 57167
Subject: Re: Quartus II for Linux
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: Tue, 24 Jun 2003 22:50:50 GMT
Links: << >>  << T >>  << A >>
Hi,

Quartus II 3.0 supports RedHat 7.1, 7.2, and 8.0.  We do not currently test
nor support RedHat 9.0.  Apparently, there have been some significant
changes in the threading libraries in 9.0.

Sorry about that,

- Paul


"H. Peter Anvin" <hpa@zytor.com> wrote in message
news:bd8mr9$cm4$1@cesium.transmeta.com...
> Since I see that some Altera people are reading this group... the
> current version of Quartus II has a Linux version, which I have access
> to; however, it's a Winelib application and they only formally support
> RedHat 7.1, which is ancient by now.  It does not work on my RedHat 9
> workstation.
>
> Does Altera have any plans to upgrade this to a modern version of
> Linux?
>
> -hpa
> -- 
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64



Article: 57168
Subject: Re: Transfer between clock domains at 350 MHz
From: hamish@cloud.net.au
Date: 24 Jun 2003 22:51:28 GMT
Links: << >>  << T >>  << A >>
Marc Randolph <mrand@my-deja.com> wrote:
> hamish@cloud.net.au wrote in message news:<3ef8003c$0$31513$5a62ac22@freenews.iinet.net.au>...
>> As part of a design I need to transfer data which is arriving on both
>> edges of a 350 MHz clock to a 175 MHz clock. The 175 MHz clock comes
>> from the divided output of the same DCM as the 350, but there could be
>> clock skew. Data is arriving on every edge of the 350 and all of it
>> needs to be transferred.
> 
> What about leaving it in the negative 350 domain a little while
> longer?  IE, make it slower/wider in the negative domain, then
> transfer it to the 175 domain?

That's a good idea, but the trick will be to co-ordinate the sampling in
the 175 MHz clock domain from the 350 MHz domain. I think that reduces
the problem from 32 or 64 bits down to 1 bit, but not all the way.

Thanks,
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 57169
Subject: Re: Quartus II for Linux
From: sdatta@altera.com (Subroto Datta)
Date: 24 Jun 2003 15:58:50 -0700
Links: << >>  << T >>  << A >>
H. Peter Anvin <hpa@zytor.com> wrote in message news:<bd8mr9$cm4$1@cesium.transmeta.com>...
> Since I see that some Altera people are reading this group... the
> current version of Quartus II has a Linux version, which I have access
> to; however, it's a Winelib application and they only formally support
> RedHat 7.1, which is ancient by now.  It does not work on my RedHat 9
> workstation.
> 
> Does Altera have any plans to upgrade this to a modern version of
> Linux?
> 
> 	-hpa

Peter,

   Quartus II does not use the WINE compatibility layer as all code is
natively compiled for Linux. Quartus II 3.0 to be released very
shortly will have support (be tested on) for RH Linux 7.1, 7.2 and
8.0. As the Linux kernel is sufficiently different between RH 8 and RH
9, Quartus II 3.0 code will probably not work on RH 9.

- Subroto Datta
Altera Corp.

Article: 57170
Subject: scaling fixed point fft
From: stenasc@yahoo.com (Bob)
Date: 24 Jun 2003 16:07:04 -0700
Links: << >>  << T >>  << A >>
Hello,

I have constructed a 256 pt complex fft. My scaling is causing
problems as the outputs from each stage are divided by 4 to avoid
overflow. The input data and the twiddle factor coeffs are 16 bits
wide (Q15). My problem is that when the data arrives at the last two
butterfly stages of the FFT, it is non-existant, due to all the
scaling beforehand. All inputs to these stages are zero. Thus I get
nothing at the output.

How can I work around this?

Many thanks 

Bob

Article: 57171
Subject: Re: PALs, GALs and ABEL
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 25 Jun 2003 11:45:13 +1200
Links: << >>  << T >>  << A >>
> "Paul Urbanus" <urbpublic@hotmail.com> wrote in message
<snip>
> > On a related note, does anyone know if the old DOS version of ABEL is in
> > the public domain? And if so, where I can download a new version.
> >
> > Of course, I could always recode the PALS in VHDL using the Cypress Warp
> > software, which used to support the 22V10, at least.
Richard Erlacher wrote:
> 
> The Lattice web site no longer has the Palasm 4 v1.5 disk set out there
> where you can readily get at it.  Translating to Palasm might be a little
> more work than going the other direction, but if your designs are in 'L'
> parts, unless you've used combinatorial-lop latches and other twisted
> constructs like that, you should have no trouble generating compatible
> equations from the ABEL sources in order to create useable jedec files for
> programming the newer parts.  with the cases you've mentioned you should
> have no problems with product term depletion or any other resource
> allocation issue, and the 20V8 and 22V10 both can replace the 'L' parts you
> meniton.

Palasm is ancient ( but I'll agree that does not stop it working :).

ABEL is becomming more closed, but can sometimes still be found under
the bonnet of bigger systems.

Atmel has WinCUPL on their web site, which is a relatively small
download,
(~10MB) and can be run command line mode from an Editor.
CUPL supports generic 16V8, 20V8 and 22V10, plus larger CPLDs, 
and can also generate test vectors, which the better chip programmers
can run to verify functional operation.

-jg

Article: 57172
Subject: Re: Transfer between clock domains at 350 MHz
From: hamish@cloud.net.au
Date: 25 Jun 2003 00:00:51 GMT
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote:
> I would generate a Clock Enable signal that is High for every even
> 350-MHz clock period, and another CE that is High for every odd period.
> Now you can clock in data into one flip-flop on the even-rising 350 MHz
> edge, and into another flip-flop on the even-falling 350 MHz edge, and
> you have a whole 350 MHz period to send the data to the appropriate 175 MHzflip-flop.
> A second set of flip-flops takes care of the odd 350 MHz period...

Aha. So although the -5 can't transfer data edge to edge at 350 MHz, it
looks like you can use data out on one edge into the enable for the
other edge with room to spare (1.2 ns path in my test route).

Thanks Peter!

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 57173
Subject: Re: Transfer between clock domains at 350 MHz
From: hamish@cloud.net.au
Date: 25 Jun 2003 00:01:54 GMT
Links: << >>  << T >>  << A >>
Morten Leikvoll <mleikvol@online.nospam> wrote:
> <hamish@cloud.net.au> skrev i melding
> news:3ef8003c$0$31513$5a62ac22@freenews.iinet.net.au...
>> As part of a design I need to transfer data which is arriving on both
>> edges of a 350 MHz clock to a 175 MHz clock. The 175 MHz clock comes
> 
> I dont know the details of the VirtexII-5, but is there a closeby dualport
> ram wich can handle 350Mhz writing? (one for positive edge and one for the
> negative (if the setup&hold times match!)). If you configure this ram with
> double datawidth out, you have the datas at 175Mhz from two ram blocks.

The LUT RAM can be written to at 350 MHz IIRC, but it doesn't have any
native way to do a width conversion. The block RAM won't run that fast.

Thanks,
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 57174
Subject: Re: Transfer between clock domains at 350 MHz
From: symon_brewer@hotmail.com (Symon)
Date: 24 Jun 2003 18:00:46 -0700
Links: << >>  << T >>  << A >>
Hey Hamish,
          Look at XAPP233, fig.10. Use latches to help generate the
enables you need. The latches give you more setup time so that it'll
work at the speeds you require.
                    cheers, Symsx.


hamish@cloud.net.au wrote in message news:<3ef8d5f0$0$31527$5a62ac22@freenews.iinet.net.au>...
> Marc Randolph <mrand@my-deja.com> wrote:
> > hamish@cloud.net.au wrote in message news:<3ef8003c$0$31513$5a62ac22@freenews.iinet.net.au>...
> >> As part of a design I need to transfer data which is arriving on both
> >> edges of a 350 MHz clock to a 175 MHz clock. The 175 MHz clock comes
> >> from the divided output of the same DCM as the 350, but there could be
> >> clock skew. Data is arriving on every edge of the 350 and all of it
> >> needs to be transferred.
> > 
> > What about leaving it in the negative 350 domain a little while
> > longer?  IE, make it slower/wider in the negative domain, then
> > transfer it to the 175 domain?
> 
> That's a good idea, but the trick will be to co-ordinate the sampling in
> the 175 MHz clock domain from the 350 MHz domain. I think that reduces
> the problem from 32 or 64 bits down to 1 bit, but not all the way.
> 
> Thanks,
> Hamish



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