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
i'd say Yes...But make sure it's only teh asynchronous reset thats causing these problems, nothing else. And even then I recommend you have a look around for debates over synch vs asynch reset... it's one of these issues that is unpredictable, and can make your circuits really misbehave... Ben "skyworld" <chenyong20000@gmail.com> wrote in message news:1172720587.730126.106160@s48g2000cws.googlegroups.com... So do you mean that I can ignore these warnings? On 2ÔÂ27ÈÕ, ÏÂÎç4ʱ57·Ö, "Benjamin Todd" <benjamin.toddREMOVEALLCAPIT...@cernREMOVEALLCAPITALS.ch> wrote: > normally you wont have specified any time constraints on the reset > signal... > I aam assuming you have a global asynchronous reset. > > To correctly manage the reset you should try to synchronise it to the > internal clock using a couple of flip-flops. This way it ensures a > synchronous release of the reset that can be treated and analysed in the > same way as any other. I think you may still get the warnings for > violations of the first asynchronous input. > > Anyways, the idea of synchronous vs asynchronous reset is a long > discussion > =) > > Ben > > "skyworld" <chenyong20...@gmail.com> wrote in message > > news:1172557239.722343.245410@p10g2000cwp.googlegroups.com... > > > Hi, > > I am doing FPGA design with xilinx spartan 3e. When I finished P&R, I > > checked the timing report. Everything is ok, and there is no timing > > violations. But when I run post simulation, the modelsim reports some > > timing errors for some registers with $recovery(...). I checked the > > time when these errors occur. They happened to be the time when reset > > is de-assertion. I tried to change reset period, but this time other > > register report $recovery/$setup/$hold errors. It is very strange > > because I have passed P&R, there is no timing violations, why does > > these errors orrur? Can anybody help me? thanks very much.Article: 116101
mtsukanov@gmail.com wrote: > Yea I actually tried doing 'id code' read, it didn't do anything, > didn't produce the same results as doing a 'blank check' or > reprogramming. check that you have the correct pullups/pulldowns on the JTAG pins.Article: 116102
Does anyone know if there is a dev kit available for an MPEG encoder ASIC - preferably one that I could connect to a real-time video source as input and connect to an FPGA board for post processing... In otherwords an MPEG ASIC dev kit with a lot of IO options. Also can anyone suggest a (separate, additional) dev kit that would support reading and riding to a hard disk, preferably one that would come with its own HDD controller onboard, that could be talked to via an external microproc or FPGA. thanksArticle: 116103
On Mar 1, 12:10 pm, "wallge" <wal...@gmail.com> wrote: > Does anyone know if there is a dev kit available for an MPEG encoder > ASIC - preferably one that > I could connect to a real-time video source as input and connect to an > FPGA board for post processing... If you already have an FPGA, why use an MPEG ASIC? You can encode MPEG in your FPGA. > Also can anyone suggest a (separate, additional) dev kit that would > support reading and riding to a hard disk, preferably one that would Again, if you have an FPGA, why do you need an external "development kit"? If you are willing to use standard parallel ATA (as opposed to the let's-line-Intel's-pockets SATA drives) it is fairly trivial to interface to a hard disk.Article: 116104
Wow. From UG076 Page 125: "It is recommended that the SONET user application enable ENPCOMMAALIGN and ENMCOMMAALIGN together, and then turn them both off when alignment is achieved." Page 195: "SONET: [...] Always keep ENPCOMMAALIGN active to prevent data misalignment." Well, it's hard to meet both rules. So which one should take precedence? KoljaArticle: 116105
<mtsukanov@gmail.com> wrote in message news:1172763684.644449.311760@n33g2000cwc.googlegroups.com... > > Hmm... I'm not completely sure I understand what u said, but let me > clarify a little more on what's happening: > > The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the > CPLD is doing is connecting the signals going from the PROM to the > FPGA - primarily the 'done' and 'd_in' pins. So, when I program the > CPLD, it works right away, and the FPGA gets programmed from the PROM. > If I turn off the POWER to the whole system, turn it back on - nothing > happens. The FPGA does'nt get programmed from the PROM. *IF at that > point I right click on the CPLD in Impact, and select 'blank check', > the CPLD starts 'working' and the FPGA gets programmed. The V4 is > working in 'master' mode, and I checked the CCLK and it runs just fine > after board powerup, thought the d_in has garbage on it. The d_in > turns good when i do the 'blank check' on the CPLD or when I reprogram > the CPLD. That's why I'm wondering if the 'blank check' drives the > CPLD's pins to 0 or 1 during the 'blank check' operation, something > funky like that > > thanks again, any help is much appreciated You have just described a system and symptom completely unrelated to the typical questions devined by the "what happens when I do this" question. You have a CPLD that doesn't just connect two parts. You have a CPLD that powers up between two parts that power up. Chances are the prom and FPGA are not both happy. The blank check for the CPLD might do something that functionally changes the I/O. Typically a blank check isn't used to ponder whether an operating device is blank so a "destructive" check is reasonable where outputs can tristate or change state while the device is interrogated. Use a logic analyzer or similar device to look at the power-up behavior of the PROM control signals as well as the FPGA program control pins. You probably have a misbehavior in the initialization because the CPLD isn't on at the right time - or correct power-on polarity - for the attached devices. Your cure may be as simple as added pull-up/pull-down resistors or a little intelligence to make sure both devices around the CPLD are in reset. The problem isn't around the "blank check" as implied by your initial superficial question (no depth) but in the CPLD's behavior in your FPGA initialization.Article: 116106
On Mar 1, 7:12 am, "John McCaskill" <junkm...@fastertechnology.com> wrote: > On Feb 28, 11:12 pm, "Brandon Jasionowski" <killerhe...@gmail.com> > wrote: > > > > > Hello, > > > I'm getting usual results from my BUFR network in Timing Analyzer: > > > <SNIP> > > -------------------------------------------------------------------------------- > > Hold Violations: TS_adc1_dclk_p = PERIOD TIMEGRP "TG_adc1_dclk_p" 4 ns > > HIGH 50%; > > -------------------------------------------------------------------------------- > > Hold Violation: -0.974ns (requirement - (clock path skew + > > uncertainty - data path)) > > Source: adc1_reg_inst/nshifts_gen[1].dff_ins/d_r_7 > > (FF) > > Destination: adc1_reg_inst/nshifts_gen[2].dff_ins/d_r_7 > > (FF) > > Requirement: 0.000ns > > Data Path Delay: 1.275ns (Levels of Logic = 0) > > Positive Clock Path Skew: 2.249ns > > Source Clock: adc1_dclk rising at 0.000ns > > Destination Clock: adc1_dclk rising at 4.000ns > > Clock Uncertainty: 0.000ns > > Timing Improvement Wizard > > Data Path: adc1_reg_inst/nshifts_gen[1].dff_ins/d_r_7 to > > adc1_reg_inst/nshifts_gen[2].dff_ins/d_r_7 > > Delay type Delay(ns) Logical Resource(s) > > ---------------------------- ------------------- > > Tcko 0.268 adc1_reg_inst/nshifts_gen[1].dff_ins/ > > d_r_7 > > net (fanout=1) 1.065 adc1_reg_inst/d_array<2><7> > > Tckdi (-Th) 0.058 adc1_reg_inst/nshifts_gen[2].dff_ins/ > > d_r_7 > > ---------------------------- --------------------------- > > Total 1.275ns (0.210ns logic, 1.065ns route) > > (16.5% logic, 83.5% route) > > </SNIP> > > > 2.25 ns positive clock path skew? Omg!? So, then I looked at the > > partially PAR'ed output on this SX55 FPGA. Turns out the stupid tools > > are expanding the BUFR network across multiple BUFR regions, including > > horizontally (x direction). I have an 8k FIFO (necessary) to > > transition from this BUFR clock to a slower BUFG clock. Looks like the > > tools are placing the FIFO on the left side of the FPGA and the top- > > right BUFR is using non BUFR resources (I assume) to route the clock > > across. > > > Is this what's causing my enormous clock path skew? I will try to > > apply some area_group slice/bram constraints to my FIFOs, but I find > > this to be an extreme pain in the butt... I'm using a COTS board, > > which is configured with 4 ADC data channels and 4 ADC clocks. The ADC > > data is about 180 degrees out of phase w/ the clock (fine). Is there a > > way to constrain nets/instances/etc. to a regional clock region? > > That'd be really sweet... > > > Is there a better way to transition from the regional clock to a > > global clock other than using a FIFO? This is giving me a headache b/c > > my design takes forever to PAR and I can't meet timing :( > > > Thanks, > > -B > > When we first started using the regional clock buffer in our designs, > the tools did not automatically place the logic that used that clock > into the three clock regions that the clock could reach. In my case, > it just failed to route. Our solution was to put an area group > constraint on the logic that used that clock, and that fixed the > problem. This was with a 7.x version of EDK/ISE. > > That little inconvenience aside, the BUFIOs and BUFRs are very nice. > The BUFR is what makes it possible for us to meet timing for 66 MHz > PCI on a V4FX60. As the FPGAs get bigger, the BUFG delays get longer. > On PCI, you should not use a DCM to tune out the clock delay because > the clock speed is allowed to vary, but I don't know how many system > do that. > > Regards, > > John McCaskillwww.fastertechnology.com Right. So I'm trying constraints like: <SNIP> INST "fifoadc1_inst" AREA_GROUP = "AG_fifoadc1_inst"; AREA_GROUP "AG_fifoadc1_inst" COMPRESSION = 100; AREA_GROUP "AG_fifoadc1_inst" RANGE = SLICE_X48Y128:SLICE_X95Y255; AREA_GROUP "AG_fifoadc1_inst" RANGE = RAMB16_X4Y16:RAMB16_X7Y31; </SNIP> Is there an area group constraint that's all encompassing, i.e. includes FIFO16, DSP48, SLICES, RAMB16, etc.? Thanks, -BrandonArticle: 116107
Well (A) the encoder IP for the FPGA is VERY expensive, (B) I am not going to write an MPEG encoder from scratch. thats why i'd rather have an ASIC and just pay for the chip itself. Also I am doing a lot of other processing on the FPGA and would like to not have to worry about saving FPGA logic/ external memory access for the the MPEG encoder. On Mar 1, 12:36 pm, "larwe" <zwsdot...@gmail.com> wrote: > On Mar 1, 12:10 pm, "wallge" <wal...@gmail.com> wrote: > > > Does anyone know if there is a dev kit available for an MPEG encoder > > ASIC - preferably one that > > I could connect to a real-time video source as input and connect to an > > FPGA board for post processing... > > If you already have an FPGA, why use an MPEG ASIC? You can encode MPEG > in your FPGA. > > > Also can anyone suggest a (separate, additional) dev kit that would > > support reading and riding to a hard disk, preferably one that would > > Again, if you have an FPGA, why do you need an external "development > kit"? If you are willing to use standard parallel ATA (as opposed to > the let's-line-Intel's-pockets SATA drives) it is fairly trivial to > interface to a hard disk.Article: 116108
The way I interpret your code as written, if the clock event happens and the reset is one, the RAM is not to be read or written. While this can be assembled manually into a memory through correct ENA usage, it probably doesn't fit the synthesis template. Consider separating the memory read/write into a separate process that has no reset. Resets - even this one which isn't "intended" to affect the memory - tend to diffuse any attempts to infer a good BlockRAM. "S.T." <st@iss.tu-darmstadt.de> wrote in message news:es6uu7$7ul$1@lnx107.hrz.tu-darmstadt.de... > Hi > > Since Version 7.x xilinx xst is able to infer block ram out of appropriate > vhdl statements. Unfortunately it is not working in the example given > below. Does anybody have an idea why the code below gives the following > warning: > > WARNING:Xst:1440 - Cannot use block RAM resources. Please check that the > RAM > contents is read synchronously. > > Thanks > ST > > library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_unsigned.all; > > entity BRAM_test is > port (CLOCK : in std_logic; > reset : in std_logic; > di : in std_logic_vector(15 downto 0); > do : out std_logic_vector(15 downto 0)); > end BRAM_test; > > architecture syn of BRAM_test is > > type ram_type is array (1023 downto 0) of std_logic_vector (15 downto 0); > signal RAM : ram_type; > attribute ram_style : string; > attribute ram_style of RAM: signal is "block"; > > type STATE_TYPE is (P1, P2, P3); > signal STATE : STATE_TYPE; > > signal addr : std_logic_vector(9 downto 0); > > begin > main : process (CLOCK, RESET) > begin > if (RESET = '1') then > STATE <= P1; > addr <= (others => '0'); > elsif (CLOCK'event and CLOCK = '1') then > case STATE is > when P1 => > RAM(conv_integer(addr)) <= di; > STATE <= P2; > when P2 => > do <= RAM(conv_integer(addr)); > STATE <= P3; > when P3 => > addr <= addr + '1'; > STATE <= P1; > end case; > end if; > end process main; > end syn; >Article: 116109
Frederic wrote: > Hello, > > I am just looking for the Jpeg 2000 source in VHDL, can anyone help > me? Free ? I think you're a little optimistic ;) And the "paying" cores are $$$ (well, that depends of the speed / profile / ... you need but not cheap). What application do you have in mind ? SylvainArticle: 116110
On Mar 1, 12:46 pm, "wallge" <wal...@gmail.com> wrote: > Also I am doing a lot of other processing > on the FPGA and would like to not have > to worry about saving FPGA logic/ external memory In that case, the best "evaluation platform" is probably a PC with a PCI MPEG encoder card and a hard disk :) Video encoder and decoder ICs tend to be terribly difficult to get without NDAs, precisely because of all the expensive IP in them (and the horrific thought that someone might build a device that doesn't comply with whatever DRM bullshit the MPAA's bought politicians are trying to peddle at the moment).Article: 116111
All, I had posted: "How else is one measured, except by their commitments? V5 has met all dates. In fact, has exceeded them." I now discover that we missed a delivery date for a shipment of ES XC5V330 parts to a customer. So, in fact, V5 XC5V330 missed a customer commitment. As the largest FPGA part in existence, we were unable to meet the demand so soon after first lot fab-out. I apologize. I also wish to thank the person who brought this to my attention, AustinArticle: 116112
Dear all, I am trying to perform a module based partial reconfiguration on a Spartan3 XC3S400 (on a 3SxLC board by MEMEC). I am using ISE 8.2.01i_PR_07b (sp1 with Early Access Patch) I already was able to perform a difference based partial reconfiguration without any problem, but when trying to perform a module based reconfiguration, when I download via JTAG the partial bitstream it seems that the device reconfigure itself totally: in fact, the static part which only switch on and off a led stops running. I created the bitstream from the ISE using these command lines: 1) the total bitstream using <bitgen -w top.ncd top.bit> 2) the partial ones using <bitgen -g ActiveReconfig:Yes -d -w partial.ncd partial.bit> In the implementing phase I use the following additional options: for the TRANSLATE phase <-u -aul> for the MAP phase <-u> Moreover when implementing the partial module synthesis I deasserted the option "Add input-output buffers" Is there someone else I should try? I tried also to create the bitstream using the pearl script (PR_verifydesign and PR_assemble) from the PR patch but I obtained some errors. For instance, when I try to merge the static module with the reconfigurable one using the PR_verifydesign static.ncd dynamic.ncd I obtain the following error "ERROR: Illegal attempt to merge two designs that are not both partial". I hope you can help me. In case you need more information please let me know LucaArticle: 116113
I know that I could just send pre-encoded video to my FPGA and skip the encoder ASIC step, but the whole point of my project is to put together an embedded system, which a desktop computer is not part of. Or at least proof of concept for an embedded system... On Mar 1, 1:01 pm, "larwe" <zwsdot...@gmail.com> wrote: > On Mar 1, 12:46 pm, "wallge" <wal...@gmail.com> wrote: > > > Also I am doing a lot of other processing > > on the FPGA and would like to not have > > to worry about saving FPGA logic/ external memory > > In that case, the best "evaluation platform" is probably a PC with a > PCI MPEG encoder card and a hard disk :) > > Video encoder and decoder ICs tend to be terribly difficult to get > without NDAs, precisely because of all the expensive IP in them (and > the horrific thought that someone might build a device that doesn't > comply with whatever DRM bullshit the MPAA's bought politicians are > trying to peddle at the moment).Article: 116114
Symon wrote: > Hey Guys, > It's a been a while since we had a bypass capacitor religious war, so I > thought I'd stir things up a bit! > Seriously, I've been reading about X2Y capacitors, and a search of the > newsgroup revealed that these very interesting parts have only been > mentioned once or twice in passing. (By Austin, natch!) > > Check out :- > http://www.teraspeed.com/publications.html > Where they ask you to register for :- > http://www.teraspeed.com/papers/cap_considerations_fpga_pds.pdf > > Steve Weir does a great job of showing why X2Y caps give you more bang for > your buck. As these parts have exceptionally low inductance, they can > substantially reduce the number of capacitors AND vias you need, and they > quote that :- > "Can replace from three to six+ regular caps depending on via and plane > geometries" > "Vias at $0.005/hole / $0.01 / capacitor typical, often COST MORE than the > capacitors they connect!" > > Here's another interesting article:- > http://www.x2y.com/bypass/mount/backside_cap.pdf > > They recommend using small 'puddles' of copper to connect all the bypass > elements together so you can use fewer capacitors but keep the same bypass > network performance. > > Check out http://www.x2y.com/bypass.htm for more articles. > > AFAICS, the main drawback is that X2Y caps are available in a range of > values. This means nutters will use several different values in their bypass > networks to create 'resonances' and the like. :-) > > Anyway, I hope this is of interest, Syms. Interesting. They are correct, but also use a couple of small 'goal post shifting' techniques. * The vias to 'their' caps, have a larger copper cross section, than to other caps. * they choose to compare 100nf (others) against their 56nf. Claiming you double their cap, is not quite correct. What they should compare, is their 56nf, against 2 x 56nF others I agree with this "Mounted ESL for an X2Y® on a 4/6 layer PCB is completely dominated by the attachment inductance..." -jgArticle: 116115
Hi, What is the running frequency for a typical FPGA application using Virtex 5? A friend of mine told me long ago that we could expect to get 1/10 running frequency of the fastest CPU for a fastest FPGA in market. Now the fastest CPU runs at 4GHz, can a FPGA application using the fastest FPGA chip be expected to run at 400MHz, 1/10 of fastest CPU? Is Virtex 5 the fastest FPGA so far? For example, DDR2 runs at 333MHz, can a DDR2 application core run normally at 333MHz without any trouble such that there is no need to reduce application core running frequency to meet 333MHz challenge? If so for Virtex 5, it can be claimed that 333MHz is achievable. 1/10 ratio between the fastest CPU and the fastest FPGA chip running frequencies is a reasonable expectation or not? Thank you. WengArticle: 116116
On Mar 1, 12:45 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > <mtsuka...@gmail.com> wrote in message > > news:1172763684.644449.311760@n33g2000cwc.googlegroups.com... > > > > > > > Hmm... I'm not completely sure I understand what u said, but let me > > clarify a little more on what's happening: > > > The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the > > CPLD is doing is connecting the signals going from the PROM to the > > FPGA - primarily the 'done' and 'd_in' pins. So, when I program the > > CPLD, it works right away, and the FPGA gets programmed from the PROM. > > If I turn off the POWER to the whole system, turn it back on - nothing > > happens. The FPGA does'nt get programmed from the PROM. *IF at that > > point I right click on the CPLD in Impact, and select 'blank check', > > the CPLD starts 'working' and the FPGA gets programmed. The V4 is > > working in 'master' mode, and I checked the CCLK and it runs just fine > > after board powerup, thought the d_in has garbage on it. The d_in > > turns good when i do the 'blank check' on the CPLD or when I reprogram > > the CPLD. That's why I'm wondering if the 'blank check' drives the > > CPLD's pins to 0 or 1 during the 'blank check' operation, something > > funky like that > > > thanks again, any help is much appreciated > > You have just described a system and symptom completely unrelated to the > typical questions devined by the "what happens when I do this" question. > > You have a CPLD that doesn't just connect two parts. You have a CPLD that > powers up between two parts that power up. > > Chances are the prom and FPGA are not both happy. The blank check for the > CPLD might do something that functionally changes the I/O. Typically a > blank check isn't used to ponder whether an operating device is blank so a > "destructive" check is reasonable where outputs can tristate or change state > while the device is interrogated. > > Use a logic analyzer or similar device to look at the power-up behavior of > the PROM control signals as well as the FPGA program control pins. You > probably have a misbehavior in the initialization because the CPLD isn't on > at the right time - or correct power-on polarity - for the attached devices. > > Your cure may be as simple as added pull-up/pull-down resistors or a little > intelligence to make sure both devices around the CPLD are in reset. > > The problem isn't around the "blank check" as implied by your initial > superficial question (no depth) but in the CPLD's behavior in your FPGA > initialization. it does surely sound like a powerup issue. BUT - if I knew what happens to the i/o of the CPLD on a 'blank check' I could put it into code so the CPLD can perform the same function once it is up and running.Article: 116117
Hi Luca, I think that you are using IMPACT to send the partial bitstreams. IMPACT sends a command (I do not remember exactly the name) before sending the bistream that stops all FPGA functionality. To test your partial bitstreams in Spartan3 while the remainder of you circuit continues working you have to use the SelectMap/JTAG interface directly without IMPACT. Regards, Ivan On Mar 1, 1:08 pm, lucaroccasa...@gmail.com wrote: > Dear all, > > I am trying to perform a module based partial reconfiguration on a > Spartan3 XC3S400 (on a 3SxLC board by MEMEC). I am using ISE > 8.2.01i_PR_07b (sp1 with Early Access Patch) > I already was able to perform a difference based partial > reconfiguration without any problem, but when trying to perform a > module based reconfiguration, when I download via JTAG the partial > bitstream it seems that the device reconfigure itself totally: in > fact, the static part which only switch on and off a led stops > running. > > I created the bitstream from the ISE using these command lines: > 1) the total bitstream using <bitgen -w top.ncd top.bit> > 2) the partial ones using <bitgen -g ActiveReconfig:Yes -d -w > partial.ncd partial.bit> > > In the implementing phase I use the following additional options: > for the TRANSLATE phase <-u -aul> > for the MAP phase <-u> > > Moreover when implementing the partial module synthesis I deasserted > the option "Add input-output buffers" > > Is there someone else I should try? > > I tried also to create the bitstream using the pearl script > (PR_verifydesign and PR_assemble) from the PR patch but I obtained > some errors. For instance, when I try to merge the static module with > the reconfigurable one using the PR_verifydesign static.ncd > dynamic.ncd I obtain the following error > "ERROR: Illegal attempt to merge two designs that are not both > partial". > > I hope you can help me. In case you need more information please let > me know > > LucaArticle: 116118
<mtsukanov@gmail.com> wrote in message news:1172776617.906745.77140@31g2000cwt.googlegroups.com... > > it does surely sound like a powerup issue. BUT - if I knew what > happens to the i/o of the CPLD on a 'blank check' I could put it into > code so the CPLD can perform the same function once it is up and > running. This approach - mimic the blank check - may set you up for failure. While it appears that you operate properly every time you perform the blank check, you're not looking at all the possible silicon and operating conditions, just what you have in front of you. Read up on how to power-up or reset the prom properly. Read up on how the CPLD I/Os behave on power up. Read up on how to properly program the FPGA. Implement a system which - by design, not by experiment - is guaranteed to work. If you insist on engineering by enecdote, please at least take a scope probe to the CPLD pins and watch what the specific signals do during that blank check operation.Article: 116119
On Mar 1, 2:49 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > <mtsuka...@gmail.com> wrote in message > > news:1172776617.906745.77140@31g2000cwt.googlegroups.com... > > > > > it does surely sound like a powerup issue. BUT - if I knew what > > happens to the i/o of the CPLD on a 'blank check' I could put it into > > code so the CPLD can perform the same function once it is up and > > running. > > This approach - mimic the blank check - may set you up for failure. While > it appears that you operate properly every time you perform the blank check, > you're not looking at all the possible silicon and operating conditions, > just what you have in front of you. > > Read up on how to power-up or reset the prom properly. > Read up on how the CPLD I/Os behave on power up. > Read up on how to properly program the FPGA. > > Implement a system which - by design, not by experiment - is guaranteed to > work. > > If you insist on engineering by enecdote, please at least take a scope probe > to the CPLD pins and watch what the specific signals do during that blank > check operation. I completely agree with you. Unfortunately, I didn't design this 'custom' board, so I have to work with what I got, which means almost all BGA parts: can't probe any line I please - no access to the pin/ trace. But yes it looks like I need to do more 'investigative' work for sure.Article: 116120
Symon <symon_brewer@hotmail.com> wrote: ... > > > Hi Uwe, > I think this is one of those few times where I'm tending > to disagree with > you. IMHO, the SI properties of the PQ208 package are so > terrible that any > prototype made using a PQ208 containing a die capable of > sub-ns rise times > is not going to accurately reflect what would happen when > you build it with > a decent FBGA package. Sure the internal logic will work ok, > but that's what > simulators are good at. Not all applications are bound by outgoing traffic. If you have many input signals, plenty available Pin are welcome, and SI issues are not that big issue... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 116121
mtsukanov@gmail.com wrote: > > it does surely sound like a powerup issue. BUT - if I knew what > happens to the i/o of the CPLD on a 'blank check' I could put it into > code so the CPLD can perform the same function once it is up and > running. That depends on the exact nature of the powerup issue - some aspects of power cycling, you cannot 'put into code'. 'blank check' (or verify, or any JTAG read ), will cycle the JTAG state engine, and exit in a known way, and do so with full Vcc on the devices. So you may have a sequecing problem. Don't Xilinx have app notes for using their CPLDs to load FPGAs ? Try their code ? -jgArticle: 116122
Uwe Bonnes wrote: > Symon <symon_brewer@hotmail.com> wrote: > ... > >>Hi Uwe, >>I think this is one of those few times where I'm tending >>to disagree with >>you. IMHO, the SI properties of the PQ208 package are so >>terrible that any >>prototype made using a PQ208 containing a die capable of >>sub-ns rise times >>is not going to accurately reflect what would happen when >>you build it with >>a decent FBGA package. Sure the internal logic will work ok, >>but that's what >>simulators are good at. > > > Not all applications are bound by outgoing traffic. If you have many > input signals, plenty available Pin are welcome, and SI issues are > not that big issue... SI covers not just the I/O but also the Vcc/Gnds, as the core switching currents need to find a low impedance. Another wrinkle in the "drop the die into a PQ208" idea, is that many now use flip chip spread bonding (bond pads over the whole die) - works very well in BGA, but rather kills using a perihperal bond package. Even MLF only gets low Z on the Gnd bondings, and FPGA's have many supplies. Having said that, there is a market for easy to deploy FPGAs (low PCB layer count ), and not just lab prototypes. The PC and Hard Drive markets are good examples of just how hard-nosed some high volume customers are about layer counts. If the fpga vendors keep driving up the PCB layer counts, and MFG machinery costs, then they will be doomed to grow at a rate that is below the fabless industry average. ( Oh, right, that's already happening....) -jgArticle: 116123
On 3=D4=C21=C8=D5, =CF=C2=CE=E77=CA=B100=B7=D6, Sylvain Munaut <tnt-at-246t= Nt- dot-...@youknowwhattodo.com> wrote: > Frederic wrote: > > Hello, > > > I am just looking for the Jpeg 2000 source in VHDL, can anyone help > > me? > > Free ? > I think you're a little optimistic ;) > > And the "paying" cores are $$$ (well, that depends of the speed / profile= / ... you need but not cheap). > > What application do you have in mind ? > > Sylvain oki, in fact, I am just looking for an example for architectural synthesis, because I have applied our tool for AES and Sobel, I want to try a more big example, I have DWT core in VHDL, and I have no time to write a jpeg by myself.Article: 116124
On Mar 1, 1:44 pm, "wallge" <wal...@gmail.com> wrote: > I know that I could just send pre-encoded > video to my FPGA and skip the encoder ASIC > step, but the whole point of my project is to put together > an embedded system, which a desktop computer is not part of. > Or at least proof of concept for an embedded system... "PC" does not imply "desktop computer". Look at embedded PC solutions from Advantech, BCM, etc.
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