Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
"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
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
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
"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 fiArticle: 57154
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
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, CaliforniaArticle: 57156
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
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.netArticle: 57158
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. > > RalphArticle: 57159
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
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
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
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 /MikeArticle: 57163
"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> > > > /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
Opencores and Xilinx have VHDL I2C code that might be of use. Though of course there is no warranty on its correctness.Article: 57166
"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
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-64Article: 57168
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
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
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 BobArticle: 57171
> "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. -jgArticle: 57172
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
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
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:
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