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
Hi Patrick, It is obvious that 256Mhz data from backplane can not framed in ONE stm-1 frame! Is important point of my question was this?! Perhaps no, It is important that: 1- Is PMC_SPECTRA able to get DS3 signals (PDH) and convert them to STM-1 (SDH)? Does PMC_SPECTRA need not any special overhead on DS3 signals? Is SPECTRA is sufficient for transfering signal from PDH world to SDH world? (Now the answer is yes, SPECTRA can convert DS3 signals-without any dedicated overhead- to SDH world STM-1 signals. ) 2- Is it easy to do temux function in my board (converting 16Mz lines to DS3 signals and vice vesa) with all configuration options in FPGA? (Now the answer is: NOT, It is not so easy, specially in receive side) Please refer to my answer to andrew in this thread for more. Anyway, thanks for your response, please let me know if there is any others. Best Regards, Masoud "Patrick MacGregor" <patrickmacgregor@comcast.net> wrote in message news:<KIydnQyxD7u2rryiU-KYvA@comcast.com>... > I think you've asked this question before, perhaps a month or two ago. As > with the last time, it isn't clear what you are trying to do. > > Do you have 16 separate inputs at 16 MHz each? If so, cramming 256 MHz > worth of data into a 155 MHz pipe is a neat trick, but not one a TEMUX can > do. Or an FPGA for that matter. > > You can cram 2 signals at 16 MHz into one DS3 rate signal, but 3 at 16 MHz = > 48 MHz, and therefore won't fit. Using this math, the best you could do is > cram 6 signals into 3 DS3's, which could fit into a 155M signal. Without > doing much math, I think you can cram maybe 9 of these 16 MHz signals into a > concatenated 155M pipe. > > But, then again, it isn't clear what you are trying to do or how you are > carving up the data. Are you selecting some subset of the 16 inputs to feed > through the STM-1 pipe? If so, how many max? What is the clock tolerance > on the 16 MHz signals? > > Can you provide any additional detail? > > > "Masoud Naderi" <naderimisc@yahoo.com> wrote in message > news:2ba3bbea.0307241443.3ba8845b@posting.google.com... > > Hi all, > > I want to use PMC-Sierra chipset for my STM-1 card. Input to this card > > is 16x16Mhz sync channels that comes from backplane. I can use > > PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to > > PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not > > cost saving and not suitable for this design, because TEMUX can do > > many things that wont use in this application. I think making DS3 > > signals from backplane signals (16Mhz) can be done easely in FPGA, so > > bypassing TEMUX chip. It should be noted that single or multi E1 > > channels should be extraced from our output STM-1 signal (for example > > from an ADM in SDH ring). > > Please help me in this regard. > > Regards. > > M. NaderiArticle: 58551
> space is not your concern directly, 1x2 inches (if fully avaiable for > components and both sides allowed) is today pretty much enough real-estate. That is 1x2 inches single sided with ~1/4" used for a 24 pin edge connector. Space is only an problem if I need more than 2-3 major ICs (flash rom, controll logic, usb logic & connector) > price is your concerne, and real one. > > flash+ram+logic for bank switching == fits the target price > > if you need USB then it comes real problem (at your target price) My target retail price is $40 with interent distributions handled by myself, so no distributer overhead. My goal is to sell a subscription service along with the device but I want to turn a small profit on the hardware in case this device gets to be popular with GBA hackers. In a pinch I could go as high as $10 for glue logic/USB logic/MP3 decoder. I miss spoke about MP3 decoding, I dont need proper MP3 logic. The system has a mono, 8bit, 24khz sound card that is driven by DMA transfers. I was hoping to have enough logic to implement a proprietary lossy decoder of some form that lets me store 20-30 minuts of audio in 1-2MB of space. If I need to I can decode my audio in software but that is not an ideal solution. My thought was to decode the compressed audio into a pair of 1k buffers and page swap them as the system empties them. Are there no FPGA/CPLD devices that have USB support built in? I know that the Altera chips have a USB programer cable but that just shifts the cost from the board to the cable. How about 3 wire busses or other low pin count communication paths? As far as reprogramming a flash via USB I dont expect to have the pin count needed to do it within my CPLD/FPGA. Im planning on using the GBA's processor to handle that. I just need to memory map my USB controller to the GBA and have a means of placing the GBA into program mode via the USB cable. The Xport mentioned earlier is a briliant product but its target audience (hoby/engineer) has a lot more free mony thain my audience (casual gamers) David TuckerArticle: 58552
> David, > > In an effort to keep your projects costs within range, we can offer > the following Intel Strata Flash at a good discount, depending on > quantity: E28F320J3A-110 at $4.50/e; E28F128J3A-150 at $11.50/e. > > -Emile Just out of curiosity, what is the difference between NAND and NOR flash memorys from the designers perspective? Given that I need a 16 bit bus and would like 100ns access time or better no mater what the arcitecture. The Toshiba NOR Flash linup is incredibly cheap compared to even the Intel Strataflash, for example the TC58V64BFT (64mbit) retails for $5.50 in quantities of 100. Is the major difference block size or is there some better reason to not use them. David TuckerArticle: 58553
david.tucker@goliathindustries.com (David Tucker) writes: > Just out of curiosity, what is the difference between NAND and NOR > flash memorys from the designers perspective? Given that I need a 16 > bit bus and would like 100ns access time or better no mater what the > arcitecture. NAND flash doesn't support random access to any location provided on the address bus. Instead it is treated like a peripheral device. You tell it "read me page 34264", then you can read that page through a data register. Page size is generally slightly more than a power of two, to leave you room for error correction bytes (or other purposes). For example, some parts I've used had 528-byte pages, 512 plus 16 for ECC.Article: 58554
If all you need to do is transport your 16M signals across a network inside of an OC-3 rate signal, then using DS3 mapping is tremendous overkill, and expensive too. It adds layers of unecessary complexity and cost. If all 16 backplane signals derive from a common clock, it would actually be a very simple matter to mux 8 of them into the payload of an OC-3c signal. You could do this with a dirt-cheap FPGA, like maybe $17 in quantity 1 pricing (I'm thinking Altera Cyclone 1C3, slowest speed grade) A CPLD might work too, and could be substantially lower power than those PMC chips you are talking about. (I'm thinking Xilinx Coolrunner perhaps). This would probably cost more, though. So, if you want to move those 16M signals across a network inside of an OC-3c, the FPGA solution would be vastly cheaper. Even if you need to use DS3's for some reason, the FPGA would still be cheaper, and use less board space/power to boot. Just my opinion. PM "Masoud Naderi" <naderimisc@yahoo.com> wrote in message news:2ba3bbea.0307251406.e39a13e@posting.google.com... > Hi Patrick, > It is obvious that 256Mhz data from backplane can not framed in ONE > stm-1 frame! Is important point of my question was this?! > Perhaps no, It is important that: > 1- Is PMC_SPECTRA able to get DS3 signals (PDH) and convert them to > STM-1 (SDH)? Does PMC_SPECTRA need not any special overhead on DS3 > signals? Is SPECTRA is sufficient for transfering signal from PDH > world to SDH world? > (Now the answer is yes, SPECTRA can convert DS3 signals-without any > dedicated overhead- to SDH world STM-1 signals. ) > > 2- Is it easy to do temux function in my board (converting 16Mz lines > to DS3 signals and vice vesa) with all configuration options in FPGA? > (Now the answer is: NOT, It is not so easy, specially in receive side) > > Please refer to my answer to andrew in this thread for more. > Anyway, thanks for your response, please let me know if there is any > others. > Best Regards, > Masoud > > > "Patrick MacGregor" <patrickmacgregor@comcast.net> wrote in message news:<KIydnQyxD7u2rryiU-KYvA@comcast.com>... > > I think you've asked this question before, perhaps a month or two ago. As > > with the last time, it isn't clear what you are trying to do. > > > > Do you have 16 separate inputs at 16 MHz each? If so, cramming 256 MHz > > worth of data into a 155 MHz pipe is a neat trick, but not one a TEMUX can > > do. Or an FPGA for that matter. > > > > You can cram 2 signals at 16 MHz into one DS3 rate signal, but 3 at 16 MHz = > > 48 MHz, and therefore won't fit. Using this math, the best you could do is > > cram 6 signals into 3 DS3's, which could fit into a 155M signal. Without > > doing much math, I think you can cram maybe 9 of these 16 MHz signals into a > > concatenated 155M pipe. > > > > But, then again, it isn't clear what you are trying to do or how you are > > carving up the data. Are you selecting some subset of the 16 inputs to feed > > through the STM-1 pipe? If so, how many max? What is the clock tolerance > > on the 16 MHz signals? > > > > Can you provide any additional detail? > > > > > > "Masoud Naderi" <naderimisc@yahoo.com> wrote in message > > news:2ba3bbea.0307241443.3ba8845b@posting.google.com... > > > Hi all, > > > I want to use PMC-Sierra chipset for my STM-1 card. Input to this card > > > is 16x16Mhz sync channels that comes from backplane. I can use > > > PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to > > > PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not > > > cost saving and not suitable for this design, because TEMUX can do > > > many things that wont use in this application. I think making DS3 > > > signals from backplane signals (16Mhz) can be done easely in FPGA, so > > > bypassing TEMUX chip. It should be noted that single or multi E1 > > > channels should be extraced from our output STM-1 signal (for example > > > from an ADM in SDH ring). > > > Please help me in this regard. > > > Regards. > > > M. NaderiArticle: 58555
OK, that's what I needed to know. Thanks, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Steve Lass" <lass@xilinx.com> wrote in message news:3F21A724.20500@xilinx.com... > Martin Euredjian wrote: > > >Vikram Pasham <Vikram.Pasham@xilinx.com> wrote: > > > > > > > >>MPPR is used when PAR fails to meet timing constraints by a small margin with > >>the default cost table. Each cost table would serve as a seed for PAR algorithm > >>and result in a different placement and routing. One of these results may meet > >>your timing constraints, otherwise MPPR will indicate the best placement and > >>routing it achieved with the given cost tables. > >> > >>In your case all these MPPR results meet your timing constraints, as the timing > >>score is zero. Timing score is simply a summation in picoseconds of all timing > >>violations. You can use any of these cost table as long as your timing > >>constraints are met by PAR. The following solution record explains on how to > >>interpret MPPR report > >> > >> > > > >Thanks for your post. This much I knew, for it is available > >information in the documentation. > > > >My question had to do with the procedure to follow after running MPPR. > > Somewhere I saw a blurb about going back to P&R and running it in > >"Re-entrant" mode. > > > This would be for the case where none of the cost tables met your timing > constraint. You would > take the one with the lowest timing score and run re-entrant route on > that ncd. > > > But, I couldn't find what this really means and > >how it uses the results of MPPR. It seems to me that the easiest > >procedure is to simply re-run P&R with the best seed table (per the > >MPPR report). > > > There is no reason to rerun PAR becaue you already have the NCDs. If > the timing score is 0, > the only way to tell which one is best is with the design score. The > design score was created > about 12 years ago for the XC3000 family and although it might be some > indication of which > table is best, it probably will not match the criteria you might say is > best for your design. > > In addition, just because one table is the best for your current design > does not mean it would > be the best if you made a minor change to your design. > > > Is that pretty much the extent fo the relationship > >between MPPR and P&R? > > > The relationship is that if you run MPPR on 3 cost tables, then ran PAR > on table 1, then 2, then 3, > you would have the same results. > > The way you use it is for cases when your design does not route or does > not meet timing running > PAR. The, you would run MPPR to see if it can meet timing running > multiple cost tables. If it > doesn't, but gets close, then you take the best one and run re-entrant > route. > > Steve > > > > >Thanks again, > > > >-Martin > >(posting from hotmail 'cause sbc/pacbell usenet servers seem to be in > >dire need of maintenance or exorcism) > > > > >Article: 58556
NOR flash requires larger write (and erase blocks), NAND is cheaper but not entirely stable reading from one "page" can generate errors on other pages. Often NAND is configured in pages of 512 + 32 with the additional 32 bytes being an error correcting code for the 512 bytes. As far as I know Toshiba only makes NAND. In applications that large amounts of data are required without significant performance requirements (digital cameras, MP3 players etc...) NAND is the right choice, on the other hand when you need performance and reliablity NOR is the way to go. david.tucker@goliathindustries.com (David Tucker) wrote in message news:<e67c452f.0307251434.458f6cb6@posting.google.com>... > > David, > > > > In an effort to keep your projects costs within range, we can offer > > the following Intel Strata Flash at a good discount, depending on > > quantity: E28F320J3A-110 at $4.50/e; E28F128J3A-150 at $11.50/e. > > > > -Emile > > Just out of curiosity, what is the difference between NAND and NOR > flash memorys from the designers perspective? Given that I need a 16 > bit bus and would like 100ns access time or better no mater what the > arcitecture. > > The Toshiba NOR Flash linup is incredibly cheap compared to even the > Intel Strataflash, for example the TC58V64BFT (64mbit) retails for > $5.50 in quantities of 100. > > Is the major difference block size or is there some better reason to > not use them. > > David TuckerArticle: 58557
Ok, I have what might be a simple question for a circuit and a design I came up with. I just want to know if I could have made life easier... I have a signal (call it "go_high") that's synchronous to my system clock (output is from a DFF) that goes high and stays high for at least 2 clock cycles, but upto 200. I wanted to make a circuit that detects an edge on "go high" and gives an output for no more than 2 clock cycles. My design: I used two DFF, with D on FF_1 tied high and GO_HIGH being pushed into the clock input on FF_1. I took FF_1_Q into FF_2_D which is clocked by system clock. FF_2_Q feeds the async. clear input on FF_1. Could I have eliminated FF_2 and just used GO_HIGH as a clock on FF_1? Regards. -- JayArticle: 58559
"Andrew Paule" <lsboogy@qwest.net> wrote in message = news:N3XTa.135$TT2.41910@news.uswest.net... > Hi Chris - >=20 > don't do it - learning ABEL is a little like learning FORTran. = Verilog=20 > is my choice, and if you need help, there are many of us who do it for = > fun and mentoring. It's relatively easy for simple projects, and gets = > you away from vendor specific tools. VHDL is another fairly easy=20 > language, and it seems to be hanging around well. Either of these is=20 > becoming sort of like C (verilog and C are easy to transport and=20 > interface hardware/software designs, as the basic structure usage is=20 > very similar). >=20 > Andrew No its nothing like learning fortran. Fortran is still going strong and supported by many vendors including Absoft, Cray, Intel, HP, IBM,Nag,Na software, NEC,=20 Sun, Sgi, Lahey / Fujistsu, Salford, and others. Compilers avaiable for windows(x86 and itanium) ,linux , mac os9 and = osx, Aix, solaris. Fortran 2000 will support fully object oriented fortran. Fortran 95 is the current standard. For information and resources=20 find on google or click on this link beuhs8$ptv$05$1@news.t-online.com http://groups.google.com/groups?q=3DFortran+Resources(July)&hl=3Den&lr=3D= &ie=3DUTF-8&oe=3DUTF-8&safe=3Doff&selm=3Dah5u7f%24ekd%2407%241%40news.t-o= nline.com&rnum=3D1 Next you'll be saying cobol is dead. Try telling that to the guys racking in the cash in the financal = industry supporting new and legacy cobol code. The new microsoft.net has multiple fortran dot net compilers and=20 one or two cobol dot net compilers. Looking at the numbers you would probably find a similar number of people using fortran as vhdl. For a few fortran links http://developer.intel.com/software/products/ http://www.polyhedron.com/compare.html http://www.polyhedron.com/complnx.html http://www.fortran.com/ AlexArticle: 58560
"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message = news:bfpdmv$3mp$1@sass2141.sandia.gov... > Hi: >=20 > I have read a little about ABEL, and it seems simpler than VHDL and=20 > Verilog. I need to learn an HDL quickly so I want to use the easiest=20 > one, for starters. >=20 > I need to design relatively simple logic, usually just combinatorial=20 > glue logic, but also some asynchronous logic. >=20 > I wonder if ABELs simplicity might make it unable to express=20 > asynchronous logic well, in which case I might be better off with a = more=20 > complex language. >=20 > An example of a more complex project that I might be facing, is to=20 > implement a triggered 16-bit counter. An asynchronous trigger signal=20 > will have to reset the counter, and then initiate counting. I picture = > using a fast clock of 10-20MHz to synchronize the async trigger, and=20 > reset the clock. A slow count clock of about 1MHz will then clock the = > counter. >=20 > I have tired of trying to use Xilinx ECS schematic editor after=20 > implementing a modulo-40 Johnson counter in that just for fun. Ouch! >=20 > What language would you recommend? >=20 > Thanks. Don't forget if you have protel you can do schematic based fpga and cpld designs in it. Also supports cupl and vhdl. You will still need the fpga companies tools for implementation and downloading to the device.=20 AlexArticle: 58561
Hi, Could anyone suggest Virtex II 6M/8M boards with PCI 66/PCIX or AGP interfaces. Thanks AndyArticle: 58562
Hi, Can anyone tell me what is Multi Cycle path and False path? thanks LijoArticle: 58563
Hi Patrick again, thanks for your response. 1- I want to send ALL 16M signals to a STANDARD far side on SDH network. It means the far side should extract standard E1 signals from my signals, So I can not mux 16M channels to OC3c payload (sending raw and unframed data). I must follow standard PDH hierarchies for going to SDH highway. 2- If we decide to send/receive raw data on/from STM-1 payload and doing this by fpga, an important problem occure: How desynchronize data from SDH side to frames and clocks of system side (PDH)? It require huge elastic buffers that doesn't exist on CPLDs, so we must external RAM chips. we require a very precise oscillator and low jitter PLL for this also. They used for clock generation (155Mhz) and locking PDH side to SDH side as slave ( or master in some cases). All of this done in PMCs chipsets. 3- In my application because all channels are synchronous together it seems seperate vt/tu mapping is not required, and we can convert 16M channels to DS3s directly. This conversion done by temux. using fpga instead of temux, coding in transmit side is easy but not in receive side Best Regards. "Patrick MacGregor" <patrickmacgregor@comcast.net> wrote in message news:<jYSdnRt2scf2SbyiXTWJkg@comcast.com>... > If all you need to do is transport your 16M signals across a network inside > of an OC-3 rate signal, then using DS3 mapping is tremendous overkill, and > expensive too. It adds layers of unecessary complexity and cost. > > If all 16 backplane signals derive from a common clock, it would actually be > a very simple matter to mux 8 of them into the payload of an OC-3c signal. > You could do this with a dirt-cheap FPGA, like maybe $17 in quantity 1 > pricing (I'm thinking Altera Cyclone 1C3, slowest speed grade) > > A CPLD might work too, and could be substantially lower power than those PMC > chips you are talking about. (I'm thinking Xilinx Coolrunner perhaps). > This would probably cost more, though. > > So, if you want to move those 16M signals across a network inside of an > OC-3c, the FPGA solution would be vastly cheaper. Even if you need to use > DS3's for some reason, the FPGA would still be cheaper, and use less board > space/power to boot. > > Just my opinion. > > PM > > "Masoud Naderi" <naderimisc@yahoo.com> wrote in message > news:2ba3bbea.0307251406.e39a13e@posting.google.com... > > Hi Patrick, > > It is obvious that 256Mhz data from backplane can not framed in ONE > > stm-1 frame! Is important point of my question was this?! > > Perhaps no, It is important that: > > 1- Is PMC_SPECTRA able to get DS3 signals (PDH) and convert them to > > STM-1 (SDH)? Does PMC_SPECTRA need not any special overhead on DS3 > > signals? Is SPECTRA is sufficient for transfering signal from PDH > > world to SDH world? > > (Now the answer is yes, SPECTRA can convert DS3 signals-without any > > dedicated overhead- to SDH world STM-1 signals. ) > > > > 2- Is it easy to do temux function in my board (converting 16Mz lines > > to DS3 signals and vice vesa) with all configuration options in FPGA? > > (Now the answer is: NOT, It is not so easy, specially in receive side) > > > > Please refer to my answer to andrew in this thread for more. > > Anyway, thanks for your response, please let me know if there is any > > others. > > Best Regards, > > Masoud > > > > > > "Patrick MacGregor" <patrickmacgregor@comcast.net> wrote in message > news:<KIydnQyxD7u2rryiU-KYvA@comcast.com>... > > > I think you've asked this question before, perhaps a month or two ago. > As > > > with the last time, it isn't clear what you are trying to do. > > > > > > Do you have 16 separate inputs at 16 MHz each? If so, cramming 256 MHz > > > worth of data into a 155 MHz pipe is a neat trick, but not one a TEMUX > can > > > do. Or an FPGA for that matter. > > > > > > You can cram 2 signals at 16 MHz into one DS3 rate signal, but 3 at 16 > MHz = > > > 48 MHz, and therefore won't fit. Using this math, the best you could do > is > > > cram 6 signals into 3 DS3's, which could fit into a 155M signal. > Without > > > doing much math, I think you can cram maybe 9 of these 16 MHz signals > into a > > > concatenated 155M pipe. > > > > > > But, then again, it isn't clear what you are trying to do or how you are > > > carving up the data. Are you selecting some subset of the 16 inputs to > feed > > > through the STM-1 pipe? If so, how many max? What is the clock > tolerance > > > on the 16 MHz signals? > > > > > > Can you provide any additional detail? > > > > > > > > > "Masoud Naderi" <naderimisc@yahoo.com> wrote in message > > > news:2ba3bbea.0307241443.3ba8845b@posting.google.com... > > > > Hi all, > > > > I want to use PMC-Sierra chipset for my STM-1 card. Input to this card > > > > is 16x16Mhz sync channels that comes from backplane. I can use > > > > PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to > > > > PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not > > > > cost saving and not suitable for this design, because TEMUX can do > > > > many things that wont use in this application. I think making DS3 > > > > signals from backplane signals (16Mhz) can be done easely in FPGA, so > > > > bypassing TEMUX chip. It should be noted that single or multi E1 > > > > channels should be extraced from our output STM-1 signal (for example > > > > from an ADM in SDH ring). > > > > Please help me in this regard. > > > > Regards. > > > > M. NaderiArticle: 58564
Multicycle paths are paths between registers that intentionally take more than one clock cycle to become stable. For example a register may need to trigger a signal every second or third rising clock edge. A False path is any path that is not relevant to a circuit's operation. A good description of both multicycle and false paths can be found in the following Timing Analysis App Note: http://www.altera.com/literature/an/an123.pdf Subroto Datta Altera Corp. "LIJO" <lijo_eceNOSPAM@hotmail.com> wrote in message news:bftlvd$iao78$1@ID-159866.news.uni-berlin.de... > Hi, > Can anyone tell me what is Multi Cycle path and False path? > > thanks > Lijo > > > >Article: 58565
Jay,
Generally speaking, you want to avoid multi-clock or asynchronous design
whenever you can get away with a simple synchronous one. Using a data
signal (like go_high) as a clock is dangerous unless you can guarentee that
the logic generating this signal is glitch-free. If the signal has
glitches, you could get multiple clock events when you didn't intend to. In
this case, you indicate it comes from a DFF so you're probably ok. But what
about when someone decides to go change that part of the design, not
realizing that your part of the system relies on a glitch-free signal?
In this case, why not do this?
FF.D = go_high
FF.clk = system clock
your function = !go_high && FF.Q
This will give you a pulse that will be high for one edge of the system
clock. If you need it to be a full cycle long, then you can register the
output.
Regards,
Paul Leventis
Altera Corp.
"Jay" <se10110@yahoo.com> wrote in message
news:MPG.198be88c83c8b6aa9896b4@news.surfcity.net...
> Ok,
>
> I have what might be a simple question for a circuit and a design I came
> up with. I just want to know if I could have made life easier...
>
> I have a signal (call it "go_high") that's synchronous to my system
> clock (output is from a DFF) that goes high and stays high for at least
> 2 clock cycles, but upto 200.
>
> I wanted to make a circuit that detects an edge on "go high" and gives
> an output for no more than 2 clock cycles.
>
> My design: I used two DFF, with D on FF_1 tied high and GO_HIGH being
> pushed into the clock input on FF_1. I took FF_1_Q into FF_2_D which is
> clocked by system clock. FF_2_Q feeds the async. clear input on FF_1.
>
> Could I have eliminated FF_2 and just used GO_HIGH as a clock on FF_1?
>
> Regards.
>
> -- Jay
>
>
Article: 58566
Rising edge detection
go_high_rising_edge = go_high AND (NOT go_high_delay_1)
Falling edge detection
go_high_falling_edges = (NOT go_high) AND go_high_delay_1
Both edges detection
go_high_both_edges = go_high XOR go_high_delay_1
Where go_high_delay_1 is go_high signal delayed by 1 system clock.
Jim
jimwu88NOOOOOOSPAM@yahoo.com
Jay <se10110@yahoo.com> wrote in message news:<MPG.198be88c83c8b6aa9896b4@news.surfcity.net>...
> Ok,
>
> I have what might be a simple question for a circuit and a design I came
> up with. I just want to know if I could have made life easier...
>
> I have a signal (call it "go_high") that's synchronous to my system
> clock (output is from a DFF) that goes high and stays high for at least
> 2 clock cycles, but upto 200.
>
> I wanted to make a circuit that detects an edge on "go high" and gives
> an output for no more than 2 clock cycles.
>
> My design: I used two DFF, with D on FF_1 tied high and GO_HIGH being
> pushed into the clock input on FF_1. I took FF_1_Q into FF_2_D which is
> clocked by system clock. FF_2_Q feeds the async. clear input on FF_1.
>
> Could I have eliminated FF_2 and just used GO_HIGH as a clock on FF_1?
>
> Regards.
>
> -- Jay
Article: 58567There is a short and good example on multi-cycle path. Thanks. http://www.saros.co.uk/hdlsolutions/appsnotes/leonardo/SAN001.pdf - Ray In comp.arch.fpga Subroto Datta <sdatta@altera.com> wrote: > Multicycle paths are paths between registers that intentionally take more > than one clock cycle to become stable. For example a register may need to > trigger a signal every second or third rising clock edge. > A False path is any path that is not relevant to a circuit's operation. > A good description of both multicycle and false paths can be found in the > following Timing Analysis App Note: > http://www.altera.com/literature/an/an123.pdf > Subroto Datta > Altera Corp. > "LIJO" <lijo_eceNOSPAM@hotmail.com> wrote in message > news:bftlvd$iao78$1@ID-159866.news.uni-berlin.de... >> Hi, >> Can anyone tell me what is Multi Cycle path and False path? >> >> thanks >> Lijo >> >> >> >> --Article: 58568
>The only 64 bit polynomial that I know of, (listed in Numerical Recipes if >one is interested) has very few 1's, so should be convenient for >implementing. AMCC made a chip that computed a 64 bit CRC 32 bits at a time. That was many years ago, so I assume they have dropped the part by now. I took a quick scan and couldn't find find any info. I did find a paper on a HIPPI over Sonet box that used it. The polynomial and logic were designed at DEC. I'm pretty sure they idn't do anything to minimize the number of bits in the polynomial. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 58569
>I've found that meeting basic timing constraints (like PERIOD) does not >guarantee that good logic (meaning that the HDL is good) will work. That, >BTW, to me, is one of the most frustrating aspects of FPGA's: good code != >working device. I'd try real hard to find out what/where the problem is. Is it something in the design that I missed? (Like the IOBs mentioned in this discussion.) If so, that's easy to fix and I won't have any more problems. Or it could be something "interesting", like bugs in the tools, or the silicon, or the board, or ... -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 58570
I'm thinking that it may have had something to do with skew in my burst counter. That's one possible scenario that could explain the design failing when switching from an up to a down counter. Maybe. Is there a way to constrain skew of a registered output word arriving at combinatorial logic inputs? Say, an 8-bit counter going into an 8-bit comparator. BTW, since utilizing an area constraint for the module in question things have been rock solid. I tested the board through temperature and voltage variations and no problems were revealed. Thanks, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Hal Murray" <hmurray@suespammers.org> wrote in message news:vi6hr8lgspf589@corp.supernews.com... > >I've found that meeting basic timing constraints (like PERIOD) does not > >guarantee that good logic (meaning that the HDL is good) will work. That, > >BTW, to me, is one of the most frustrating aspects of FPGA's: good code != > >working device. > > I'd try real hard to find out what/where the problem is. > > Is it something in the design that I missed? (Like the IOBs mentioned > in this discussion.) If so, that's easy to fix and I won't have > any more problems. > > Or it could be something "interesting", like bugs in the tools, > or the silicon, or the board, or ... > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam. >Article: 58571
Hi, I am after a book with a title something along the lines of ``VHDL for Software Engineers'' Finding a suitable book seems pretty challenging as most assume either the reader is an experienced electrical engineer or that they are a complete novice coming in. I have years of Computer Science background and am trying to become more aquainted with the actual hardware design. FWIW the Linux port I mentioned before has now progressed further and I am in the process of adding support for various Xilinx devices. Jon.Article: 58572
Hi Jon, I'd highly recommend "Fundamentals of Digital Logic with VHDL Design" by Stephen Brown and Zvonko Vranesic. It is used as an introduction to both digital logic and VHDL in 2nd or 3rd year EE/CE courses at the University of Toronto. It has a lot of examples and presents the material in a logical order. Some CS grads we've hired have used this text to learn about hardware and people seem to like it. There is also a Verilog version that just came out this year. Go here to read a bit more about it: http://auth.mhhe.com/engcs/electrical/brownvranesic/index_vhdl.mhtml Regards, Paul Leventis Altera Corp. "Jon Masters" <jonathan@jonmasters.org> wrote in message news:vi7lc8p5i8su25@corp.supernews.com... > Hi, > > I am after a book with a title something along the lines of > > ``VHDL for Software Engineers'' > > Finding a suitable book seems pretty challenging as most assume either > the reader is an experienced electrical engineer or that they are a > complete novice coming in. I have years of Computer Science background > and am trying to become more aquainted with the actual hardware design. > > FWIW the Linux port I mentioned before has now progressed further and I > am in the process of adding support for various Xilinx devices. > > Jon. >Article: 58573
Hi, I would like to know what the actual/future FPGA research topics are. I found a lot of research papers concerning the following topics: - low power designs - asynchronous desings - software radio - neural networks - dynamic reconfiguration - evolvable hardware - field programmable analog array Are these topics still research fields ? What are the future research fields ? Thanks in advance.Article: 58574
Hi Paul, How specific to Altera is this book? Cheers, Jon.
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