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
jay wrote: > Hi all, > > For the ram implied in a CPLD design, will the data written in it > remain after power off? > > I have a small rom in my curent CPLD design, occasionally I need > change the content inside, instead of reprogramming it, I want > something like a nvram that I can update through the uP dynamicallly. That depends on the CPLD. Some do have a mode, where you can load the CPLD config latches and not the NV_Fuse_memory. (I think Atmel ATF15xxBE series have the twin modes) not sure of the details, ie when the change-over occurs and what the pins do during re-load -jgArticle: 133401
On 6=A4=EB25=A4=E9, =A4U=A4=C84=AE=C914=A4=C0, Jens Hagemeyer <je...@hni.up= b.de> wrote: > On 24 Jun., 09:19, grant0920 <grant0...@gmail.com> wrote: > > > > > > > Hi All: > > > There are many papers about the 1D or 2D placement. However, > > the papers are almost for the algorithm discussion. The current method > > for dynamically partially reconfigurable architectures is EAPR flow, > > but the DPR blocks need to be defined at design-time by using the ucf > > file. All the area constraints are finally included in the static_full > > and partial bitstreams. So, I am very confused how 1D and 2D placement > > can be applied to a "real" DPR system at run-time. Are there any > > research groups who can apply such placement methods in a "real" DPR > > architecture? I know that some proposed methods, which contained a > > specific filter to re-modify the location information in the > > bitstream, can relocate a partial bitstream to a new location. > > However, the area sizes of DPR blocks need to be the same. However, > > for example, two DPR blocks are implemented at design-time. Is it > > possible that the two DPR areas can be merged for placing a partial > > bitstream that needs both the resources of two DPR blocks like real 1D > > or 2D placement at run-time? Is there any architecture that can freely > > be placed the partial bitstreams at run-time? Thanks very much! > > > Best regards, > > Huang > > Hi Huang, > > if you like, you can have a look at the following papers from FPL 2007 > and ERSA 2007: > > "A Design Methodology for Communication Infrastructures on partially > reconfigurable FPGAs", presented at FPL 2007, shows a design flow, > which allows to place several hardware modules within a partial > reconfiguration region. Thus, the resources can be used more efficient > than compared to other approaches. "Design of Homogeneous > Communication Infrastructures for Partially Reconfigurable FPGAs", > presented at ERSA 2007, can be seen as an addition to the FPL-Paper. > An "embedded communication macro" is introduced which enables the > communication between the modules. > > The methods can be used for 1D as well as 2D placement. > > Best Regrads, > > Jens- =C1=F4=C2=C3=B3Q=A4=DE=A5=CE=A4=E5=A6r - > > - =C5=E3=A5=DC=B3Q=A4=DE=A5=CE=A4=E5=A6r - Thanks very much for Stephen and Jens. Jens, are you the author of the two papers that you suggested? I have read your papers and I am interested in your works. Do you have detial reports about the issue? Thanks very much :)Article: 133402
KJ schrieb: > "KJ" <kkjennings@sbcglobal.net> wrote in message > news:tZS8k.1343$np7.1219@flpi149.ffdc.sbc.com... > Slight correction to previous, I missed the word 'inactive' in your sentence > "And if Reset is tied to a constant inactive value..". This means then the > latter part of my post was not correct, but the first part still is. > > In any case, the code inside the "if Reset = '1' then" portion will be > synthesized away, and no assignments having to do with 'init_vector' will > occur, ever...not a very good replacement for an initial value assignment. > > Kevin Jennings > > Hi Kevin, Generally I agree to what you say, but to my excuse I also said that I'm not 100% sure about it. That's because as far as I remember there was some other posting about this topic some time ago. There it was said, that XST "recognizes" these values and puts them in the bitstream regardless of the later optimization of the reset net. But I may remember wrong. (Did anyone try it on some hardware?) Still, with a reset signal it will work. And if Rob is using the internal reset net (GSR) of the startup block he hasn't even to waste an I/O pin and the initialisation will occur only once at power up. (And as far as I understood power up initialisation is Robs problem, not at any other time) Do you confirm with this alternative solution? Best regards EilertArticle: 133403
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:f2e0b12a-9e90-4b82-9380-bcb21d228d7c@t12g2000prg.googlegroups.com... > Starting on April 20 this year there was a 3-week long thread about > quadrature decoding. 85 postings!!! > Let me summarize for a beginner: > You should assume that the quadrature input is asynchronous, can have > totally undefined duty cycle (down to pulses below 1 ns) and will have I had the foresight to connect the encoder with 6" of unshielded cable. ;)Article: 133404
Thanks , it works. On Jun 26, 8:17 pm, Jim Wu <jimwu88NOOOS...@yahoo.com> wrote: > Forgot to mention that the "Constraints Guide" PDF in %XILINX%\doc > \usenglish\books\docs\cgd is a good reference for constraint related > issue. > > Cheers, > Jim (jimwu88 NOOOSPAM at yahoo NOOOSPAM dot com)http://home.comcast.net/%7Ejimwu88/tooArticle: 133405
On 6=D4=C227=C8=D5, =CF=C2=CE=E71=CA=B152=B7=D6, Jim Granville <no.s...@des= igntools.maps.co.nz> wrote: > jay wrote: > > Hi all, > > > For the ram implied in a CPLD design, will the data written in it > > remain after power off? > > > I have a small rom in my curent CPLD design, occasionally I need > > change the content inside, instead of reprogramming it, I want > > something like a nvram that I can update through the uP dynamicallly. > > That depends on the CPLD. > Some do have a mode, where you can load the CPLD config > latches and not the NV_Fuse_memory. > (I think Atmel ATF15xxBE series have the twin modes) > > not sure of the details, ie when the change-over occurs > and what the pins do during re-load > > -jg Thanks, but I'm only using a general CPLD from A. JayArticle: 133406
> If you've got data lines only (no clock or async handshaking), you > need clock transferred by some other method - either explicitly or in > a way that the clock can be extracted/implied from the data stream. Yes, I just need the data lines forwarded from the control to the target FPGA. The target FPGA has an own clock so I dont need to forward this signal Thx, H.Article: 133407
On Jun 27, 10:11=A0pm, Heinrich <Heinr...@myweb.com> wrote: > > If you've got data lines only (no clock or async handshaking), you > > need clock transferred by some other method - either explicitly or in > > a way that the clock can be extracted/implied from the data stream. > > Yes, I just need the data lines forwarded from the control to the target > FPGA. The target FPGA has an own clock so I dont need to forward this sig= nal > > Thx, > H. OK, I don't want to keep saying the same thing, but are you sure the clock on the target FPGA is synchronous (coherent) with the one on the control FPGA? Can you guarantee their relative phase? If you are using DCMs then you probably can't. If not, like I said, you need to make special efforts to cross the clock boundary correctly. I just want to make sure you are aware of this. Regards TomArticle: 133408
On Thu, 26 Jun 2008 18:24:38 +0200, Thorsten Kiefer <webmaster@nillakaes.de> wrote: >Hi, >synthesizing the following code yields an error. What happened in simulation? In Modelsim, you can use the "drivers" command to find out exactly what drivers are connected to the signal in question; that gos a long way to finding the problem. - BrianArticle: 133409
Thank you very much for your feedback, so far! Oh my.... I'm sorry. That was definitely a spelling mistake: it's supposed to be "26290144 elements". Sorry 'bout that! Regards Norman BollmannArticle: 133410
> > OK, I don't want to keep saying the same thing, but are you sure the > clock on the target FPGA is synchronous (coherent) with the one on the > control FPGA? > > Can you guarantee their relative phase? If you are using DCMs then you > probably can't. > If not, like I said, you need to make special efforts to cross the > clock boundary correctly. > I just want to make sure you are aware of this. Thanks Tom, they have both the same clock Frequency but the phase doesnt matter as it is just some serial databits that need to be forwarded between them. So in the meantime everything works as it should :)Article: 133411
Is there a 'normal' way to write down K-maps with more than 4 inputs? I've just written some code to verify logic which implements n-input K-maps. The user has to initialise a square or rectangular array with the function output data, so I did a quick Google search to find out how people wrote their grids. On the net, at least, it looks like the reflected binary Gray version is the normal way to do it. It's not what I was used to, but I assumed that most people would use it. Now that I've done it, though, I'm not so sure. For a 5-input function, for example, a reflected binary Gray map looks like this: // /----- A -----\ // /- B -\ /- B -\ // --------------- --------------- // | x | x | x | x | | x | x | x | x | // |---------------| |---------------| // | x | x | x | x |\ | x | x | x | x |\ // --------------- E --------------- E // / | x | x | x | x |/ / | x | x | x | x |/ // D |---------------| D |---------------| // \ | x | x | x | x | \ | x | x | x | x | // --------------- --------------- // \- C -/ \- C -/ A is the MS input, and E is the LS input. The 8 columns have left-to-right ABC codings of 000, 001, 0011, and so on. The 4 rows are coded 00, 01, 11, 10 from top-to-bottom. The coding I've used historically is different. It's still Gray-coded, of course, but it looks like this (actually, I assign A, B, C, D, E arbitrarily, but I've adjusted it to be mostly consistent with the reflected version): // /----- A -----\ // /- B -\ /- B -\ // --------------- --------------- // | x | x | x | x | | x | x | x | x | // |---------------| |---------------| // | x | x | x | x |\ | x | x | x | x |\ // --------------- E --------------- E // / | x | x | x | x |/ / | x | x | x | x |/ // D |---------------| D |---------------| // \ | x | x | x | x | \ | x | x | x | x | // --------------- --------------- // \- C -/ \- C -/ The problem with the reflected version is that it's not easy to (manually) minimise over the 2 grids, because B has moved. In the second version, you can place the two grids over each other to get your minterms. The difference is more significant for 6 variables - it's not obvious how to minimise the first version, but the second version easily turns into a 3D toroid and you can actually visualise the groups. Note that I'm not talking about machine minimisation - this is just how a human would write and visualise a 5- or 6-input map, and how they'd want to write down the function output data. If you use K-maps, which version do you prefer for 5- and 6-input functions? I clearly have to use the reflected version for more than 6 inputs; it's only 5 and 6 which are problems. Thanks - EvanArticle: 133412
On Jun 27, 3:24 am, backhus <n...@nirgends.xyz> wrote: > KJ schrieb:> "KJ" <kkjenni...@sbcglobal.net> wrote in message > >news:tZS8k.1343$np7.1219@flpi149.ffdc.sbc.com... > > Slight correction to previous, I missed the word 'inactive' in your sentence > > "And if Reset is tied to a constant inactive value..". This means then the > > latter part of my post was not correct, but the first part still is. > > > In any case, the code inside the "if Reset = '1' then" portion will be > > synthesized away, and no assignments having to do with 'init_vector' will > > occur, ever...not a very good replacement for an initial value assignment. > > > Kevin Jennings > > Hi Kevin, > Generally I agree to what you say, but to my excuse I also said that I'm > not 100% sure about it. > That's because as far as I remember there was some other posting about > this topic some time ago. > There it was said, that XST "recognizes" these values and puts them in > the bitstream regardless of the later optimization of the reset net. > > But I may remember wrong. (Did anyone try it on some hardware?) > > Still, with a reset signal it will work. And if Rob is using the > internal reset net (GSR) of the startup block he hasn't even to waste an > I/O pin and the initialisation will occur only once at power up. > (And as far as I understood power up initialisation is Robs problem, not > at any other time) > > Do you confirm with this alternative solution? > > Best regards > Eilert Haven't tried this in VHDL, but it certainly works in Verilog for XST. i.e. XST looks at the reset terms, whether or not they get optimized away, and uses this value as the INIT (configuration bit download) value. My most common approach is to have an asynchronous reset term to every module, and tie it to zero (inactive) if not needed. XST is also smart enough to take initial values from "initial" blocks in Verilog, including initialization of memory using $readmemh or $readmemb. Again I'm not sure what the VHDL equivalent would be, but it suggests that XST at least tries to match the simulation result when possible. Cheers, GaborArticle: 133413
On Jun 23, 10:12 am, XSterna <XSte...@gmail.com> wrote: > Hi, > > I was wondering if a tool exists to monitor the content of a RAM, ROM > connected to a Xilinx FPGA. > > I would like to be able to control the content of those memories like > a debugging tool for microcontroller for example. > > Does anybody know if this type of "debug" option is available for FPGA > developpment ? > > Xavier Xilinx Platform Studio SDK allows you to monitor and change any memory accessible by the embedded processor in your system. I have done this with MicroBlaze on Virtex 5, but I assume it works on the PPC processors as well. I don't know of a general tool for attached memory that is not associated with an embedded processor. Regards, GaborArticle: 133414
On Jun 27, 1:15=A0pm, Gabor <ga...@alacron.com> wrote: > On Jun 27, 3:24 am, backhus <n...@nirgends.xyz> wrote: > > > > > > > KJ schrieb:> "KJ" <kkjenni...@sbcglobal.net> wrote in message > > >news:tZS8k.1343$np7.1219@flpi149.ffdc.sbc.com... > > > Slight correction to previous, I missed the word 'inactive' in your s= entence > > > "And if Reset is tied to a constant inactive value..". This means the= n the > > > latter part of my post was not correct, but the first part still is. > > > > In any case, the code inside the "if Reset =3D '1' then" portion will= be > > > synthesized away, and no assignments having to do with 'init_vector' = will > > > occur, ever...not a very good replacement for an initial value assign= ment. > > > > Kevin Jennings > > > Hi Kevin, > > Generally I agree to what you say, but to my excuse I also said that I'= m > > not 100% sure about it. > > That's because as far as I remember there was some other posting about > > this topic some time ago. > > There it was said, that XST "recognizes" these values and puts them in > > the bitstream regardless of the later optimization of the reset net. > > > But I may remember wrong. (Did anyone try it on some hardware?) > > > Still, with a reset signal it will work. And if Rob is using the > > internal reset net (GSR) of the startup block he hasn't even to waste a= n > > I/O pin and the initialisation will occur only once at power up. > > (And as far as I understood power up initialisation is Robs problem, no= t > > =A0 at any other time) > > > Do you confirm with this alternative solution? > > > Best regards > > =A0 =A0Eilert > > Haven't tried this in VHDL, but it certainly works in Verilog for XST. > > i.e. =A0XST looks at the reset terms, whether or not they get optimized > away, and uses this value as the INIT (configuration bit download) > value. > My most common approach is to have an asynchronous reset term to > every module, and tie it to zero (inactive) if not needed. > If the async reset is tied inactive and there are no initial values specified, the synthesis tool is free to apply whatever initial values that it so chooses. If XST happens to be doing something in a way you like, then you're free to take advantage of that, but keep in mind that by doing so you're tying your design to a quirk with a particular tool (perhaps with particular versions of that tool) and you're not specifying the behaviour of your design using the design language. Reliance on tool quirks is usually not good design practice...'specially if used in situations other than where such reliance may be absolutely needed for some reason. If for some reason it is absolutely needed then you should comment this reason up in the code for later on when you find that the tool no longer does what you'd like it to be doing. > XST is also smart enough to take initial values from "initial" blocks > in Verilog, including initialization of memory using $readmemh or > $readmemb. =A0Again I'm not sure what the VHDL equivalent would be, The VHDL equivalent is specifying the initial value in the signal declaration like this signal xyz: std_ulogic :=3D '1'; > but > it suggests that XST at least tries to match the simulation result > when possible. > Well, the original poster was having a problem because the tool was ignoring the initial value specification so sim didn't match reality. Specifying an initial value that is different from what is inside the always inactive async reset portion would lead to a sim mismatch...not a plus in my book. Simple example below. signal xyz: std_ulogic :=3D '1'; -- Specify an initial powerup value of 1 =2E.. process(clk, reset) if rising_edge(clk) then xyz <=3D .... end if; if (reset =3D '1') then xyz <=3D '0'; -- But we forget and set to 0 on the async reset. end if; end process; =2E.. reset <=3D '0'; -- Now keep the reset signal inactive. If signal xyz powers up as '0' because that's what is inside the always inactive "if (reset =3D '1') then" clause when then your synthesis tool has a bug...not a feature. Kevin JenningsArticle: 133415
On Jun 27, 11:05=A0am, "Norman Bollmann" <wirdnichtgele...@gmx.net> wrote: > Thank you very much for your feedback, so far! > > Oh my.... I'm sorry. That was definitely a spelling mistake: it's suppose= d > to be "26290144 elements". Sorry 'bout that! > > Regards > > Norman Bollmann Even with 26M elements to search, as long as they're only 16bits, that's still only 65k choices. A hash table based thing as someone else pointed out would be a good option. Can you give some details about the search you need to perform? ChrisArticle: 133416
Does anyone know if this is true or not? All our programming files are based on IEEE-1532 DaveArticle: 133417
On 27 Jun, 18:09, Evan Lavelle <nos...@here.com> wrote: > Is there a 'normal' way to write down K-maps with more than 4 inputs? > > I've just written some code to verify logic which implements n-input > K-maps. The user has to initialise a square or rectangular array with > the function output data, so I did a quick Google search to find out > how people wrote their grids. On the net, at least, it looks like the > reflected binary Gray version is the normal way to do it. It's not > what I was used to, but I assumed that most people would use it. > > Now that I've done it, though, I'm not so sure. For a 5-input > function, for example, a reflected binary Gray map looks like this: > > // =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/----- = A -----\ > // =A0 =A0 =A0 =A0 =A0 =A0 /- B -\ =A0 =A0 =A0 =A0 =A0 =A0/- B -\ > // =A0 =A0 --------------- =A0 =A0 =A0 =A0 =A0 =A0--------------- > // =A0 =A0| x | x | x | x | =A0 =A0 =A0 =A0 =A0| x | x | x | x | > // =A0 =A0|---------------| =A0 =A0 =A0 =A0 =A0|---------------| > // =A0 =A0| x | x | x | x |\ =A0 =A0 =A0 =A0 | x | x | x | x |\ > // =A0 =A0 --------------- =A0E =A0 =A0 =A0 =A0 --------------- =A0E > // =A0/ | x | x | x | x |/ =A0 =A0 =A0 / | x | x | x | x |/ > // D =A0|---------------| =A0 =A0 =A0 D =A0|---------------| > // =A0\ | x | x | x | x | =A0 =A0 =A0 =A0\ | x | x | x | x | > // =A0 =A0 --------------- =A0 =A0 =A0 =A0 =A0 =A0--------------- > // =A0 =A0 =A0 =A0 \- C -/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\- C -/ > > A is the MS input, and E is the LS input. The 8 columns have > left-to-right ABC codings of 000, 001, 0011, and so on. The 4 rows are > coded 00, 01, 11, 10 from top-to-bottom. > > The coding I've used historically is different. It's still Gray-coded, > of course, but it looks like this (actually, I assign A, B, C, D, E > arbitrarily, but I've adjusted it to be mostly consistent with the > reflected version): > > // =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/----- = A -----\ > // =A0 =A0 =A0 =A0 =A0 =A0 /- B -\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0/- B -\ > // =A0 =A0 --------------- =A0 =A0 =A0 =A0 =A0 =A0--------------- > // =A0 =A0| x | x | x | x | =A0 =A0 =A0 =A0 =A0| x | x | x | x | > // =A0 =A0|---------------| =A0 =A0 =A0 =A0 =A0|---------------| > // =A0 =A0| x | x | x | x |\ =A0 =A0 =A0 =A0 | x | x | x | x |\ > // =A0 =A0 --------------- =A0E =A0 =A0 =A0 =A0 --------------- =A0E > // =A0/ | x | x | x | x |/ =A0 =A0 =A0 / | x | x | x | x |/ > // D =A0|---------------| =A0 =A0 =A0 D =A0|---------------| > // =A0\ | x | x | x | x | =A0 =A0 =A0 =A0\ | x | x | x | x | > // =A0 =A0 --------------- =A0 =A0 =A0 =A0 =A0 =A0--------------- > // =A0 =A0 =A0 =A0 \- C -/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\- C -/ > > The problem with the reflected version is that it's not easy to > (manually) minimise over the 2 grids, because B has moved. In the > second version, you can place the two grids over each other to get > your minterms. The difference is more significant for 6 variables - > it's not obvious how to minimise the first version, but the second > version easily turns into a 3D toroid and you can actually visualise > the groups. Note that I'm not talking about machine minimisation - > this is just how a human would write and visualise a 5- or 6-input > map, and how they'd want to write down the function output data. > > If you use K-maps, which version do you prefer for 5- and 6-input > functions? I clearly have to use the reflected version for more than 6 > inputs; it's only 5 and 6 which are problems. > > Thanks - > > Evan I didn't think that anyone still used Karnaugh maps for programmable logic. LeonArticle: 133418
Evan Lavelle wrote: > Note that I'm not talking about machine minimisation - > this is just how a human would write and visualise a 5- or 6-input > map, and how they'd want to write down the function output data. > > If you use K-maps, which version do you prefer for 5- and 6-input > functions? I clearly have to use the reflected version for more than 6 > inputs; it's only 5 and 6 which are problems. Is this homework ? The design is not usually going to stay on paper, it has to end up in silicon. That makes most of this irrelevent. -jgArticle: 133419
On Jun 28, 2:08=A0am, Heinrich <Heinr...@myweb.com> wrote: > they have both the same clock Frequency but the phase doesnt > matter as it is just some serial databits that need to be forwarded > between them. So if the relative phase isn't known, how does the receiving FPGA know #when# to read each data bit from the transmitting FPGA? More specifically, what happens if the receiving FPGA decides to read the value at its input pin just at the very same moment that it is being changed by the transmitting FPGA? (note: this is not good). Worse than this, there are finite setup and hold time requirements on the receiving inputs that you have to make sure are being met for data to be read reliably - that involves knowing exactly when data is being read (i.e. the phase of the clock on which reads are done versus the incoming data timing). If you can't do that, then you need to forward some other method of saying when it is "safe" to read each bit (e.g. an async strobe). The fact it is "only" serial doesn't matter. -TArticle: 133420
Tom wrote: > On Jun 28, 2:08 am, Heinrich <Heinr...@myweb.com> wrote: >> they have both the same clock Frequency but the phase doesnt >> matter as it is just some serial databits that need to be forwarded >> between them. > > So if the relative phase isn't known, how does the receiving FPGA know > #when# to read each data bit from the transmitting FPGA? > More specifically, what happens if the receiving FPGA decides to read > the value at its input pin just at the very same moment that it is > being changed by the transmitting FPGA? > (note: this is not good). > > Worse than this, there are finite setup and hold time requirements on > the receiving inputs that you have to make sure are being met for data > to be read reliably - that involves knowing exactly when data is being > read (i.e. the phase of the clock on which reads are done versus the > incoming data timing). > If you can't do that, then you need to forward some other method of > saying when it is "safe" to read each bit (e.g. an async strobe). The > fact it is "only" serial doesn't matter. > > -T Although, one of the questions that hasn't come up yet is how fast of a link and on what kind of FPGAs. Any modern part, if the OP is only trying to push 100Kbps or so, and just hooks the clocks on both FPGAs together and hopes that it just works, it really just will. There are all sorts of timescales for which the skew between the transmitting and receiving ends is effectively zero. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 133421
On Jun 26, 10:59 am, wdc.cre...@gmail.com wrote: > On Jun 25, 2:49 pm, Duth <premd...@gmail.com> wrote: > > > 11.1 is planned to be released a year after 10.1. That means plan for > > March 2009.Xilinxis considering working with some customers on a > > beta program to get feedback for the NCSim and Synopsys support. If > > interested in this, please contact yourXilinxFAE. > > > Aldec simulators are not supported byXilinxand that is why you will > > probably need to talk to Aldec to get their roadmaps. > > Thank you for an straightforward response. When I contacted Aldec > about Verilog-2005 SecureIP support, they hinted that the vendor > (Xilinx) > must provide an encrypted model for the Aldec-simulator, i.e., the > IP-publisher is responsible for re-generating the IP-model on each > supported platform (simulator.) Here's Aldec's apnote on EDK 10.1: > > http://support.aldec.com/KnowledgeBase/Article.aspx?aid=000737 > > "Import andSimulationBehavioral model including SecureIP encryption. > > Currently, the MicroBlaze behavioral model is not provided for Aldec > Active-HDL7.3sp1 simulator. If you are interested in it please askXilinxsupport to encrypt them as SecureIP for us." > > I don't know whether that's really the case... I assume the *real* > issue is more complicated than just this, otherwise EDK 10.1 would > have shipped with out-of-the-box Synopsys/VCS and Cadence/NCsim > support? Hi, You are correct in the assumption that is not just a matter of encrypting and delivering. In order to support a new simulator a lot more is involved. We need to have the correct support, engineering and testing infrastructure to handle a new simulator. If we just encrypt and ship out the product, the quality will be extremely poor. If you have questions no one in Xilinx will be able to assist you and if you find issues no one will have the knowledge to fix it. As you can see for a complete solution we need to spend a lot more than just encrypting and delivering. There is another side of this where Aldec may accept to take on support, although since this is a proprietary IP, we cant take a risk of encrypting with a vendor that we do not have a NDA agreement with. With the example of EDK and VCS lack of support it really came down to priorities. Although since Synopsys is a partner we will raise the priority if the demand from customers for this flow increases. This a glimpse to what is really involved. Hope this helps Thanks DuthArticle: 133422
On Jun 28, 8:57=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote: > Although, one of the questions that hasn't come up yet is how fast of a > link and on what kind of FPGAs. =A0Any modern part, if the OP is only > trying to push 100Kbps or so, and just hooks the clocks on both FPGAs > together and hopes that it just works, it really just will. =A0There are > all sorts of timescales for which the skew between the transmitting and > receiving ends is effectively zero. Sure, if the clock really is slow enough, and the same clock source drives both FPGAs, then there is not much to worry about. Except of course that the receiver should of course read (register) the incoming data on the opposite clock edge to the clock edge that the transmitter is using. -TomArticle: 133423
On Sat, 28 Jun 2008 09:00:03 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: >Is this homework ? I did my last "homework", as you put it, 28 years ago, in Quantum Mechanics. >The design is not usually going to stay on paper, it has to >end up in silicon. That makes most of this irrelevent. There's a common misconception that K-maps are/were only used for minimisation, so they're now irrelevant. Actually, K-maps are probably the most fundamental tool for the design, specification, and analysis of combinatorial logic. They're also independent of the implementation, which makes them ideally suited for verification of the same circuits. They're about 'what', not 'how'. An HDL description, on the other hand, is exactly the opposite - 'how', not 'what'. As I said originally, this is about verification. The fact that the K-map may or may not end up in silicon is "irrelevant". Leon asked whether anyone still used K-maps for programmable logic; a good question, without being condescending. I don't imagine many people use them to fill up FPGAs. On the other hand, I'm sure there are still people in this NG who do digital logic design, and some of them may occasionally even do non-trivial combinatorial logic.Article: 133424
Evan Lavelle wrote: > On Sat, 28 Jun 2008 09:00:03 +1200, Jim Granville > <no.spam@designtools.maps.co.nz> wrote: > > >>Is this homework ? > > > I did my last "homework", as you put it, 28 years ago, in Quantum > Mechanics. > > >>The design is not usually going to stay on paper, it has to >>end up in silicon. That makes most of this irrelevent. > > > There's a common misconception that K-maps are/were only used for > minimisation, so they're now irrelevant. Actually, K-maps are probably > the most fundamental tool for the design, specification, and analysis > of combinatorial logic. They're also independent of the > implementation, which makes them ideally suited for verification of > the same circuits. They're about 'what', not 'how'. An HDL > description, on the other hand, is exactly the opposite - 'how', not > 'what'. As I said originally, this is about verification. The fact > that the K-map may or may not end up in silicon is "irrelevant". I'm still trying to get a handle on the 'why' ? > Leon asked whether anyone still used K-maps for programmable logic; a > good question, without being condescending. I don't imagine many > people use them to fill up FPGAs. On the other hand, I'm sure there > are still people in this NG who do digital logic design, and some of > them may occasionally even do non-trivial combinatorial logic. Do you mean actual FET level logic ? Even at the lowest combinatorial logic, I still look at the tools output, and often they do eqn invert, or do D/T/XOR synthesis swapping in order to pack things more efficently. -jg
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