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
Hello Jon, You are completely correct, I do not understand the virtex 5 at all!! What guide(since there are like 10) would you recommend reading to learn about LVDS. Thank god i pinned out almost everything on my PCB to headers... just need to make a new socket board! Thanks Jgk > >It seem to me as though you dont really understand the Virtex 5 >architecture. You need to read the user guide and data sheet to get a feel >what is possible with a certain IO technology. Rocket IO uses CML type >drivers which are different to LVDS. LVDS upto 1.25 Gb/s is possible. > >Jon > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152076
>Hello Jon, > >You are completely correct, I do not understand the virtex 5 at all!! >What guide(since there are like 10) would you recommend reading to learn >about LVDS. Thank god i pinned out almost everything on my PCB to >headers... just need to make a new socket board! > >Thanks > >Jgk >> >>It seem to me as though you dont really understand the Virtex 5 >>architecture. You need to read the user guide and data sheet to get a >feel >>what is possible with a certain IO technology. Rocket IO uses CML type >>drivers which are different to LVDS. LVDS upto 1.25 Gb/s is possible. >> >>Jon >> >>--------------------------------------- >>Posted through http://www.FPGARelated.com >> > >--------------------------------------- >Posted through http://www.FPGARelated.com > Just go to the Virtex 5 documentation page. There is the User Guide which will give you info about all the tech inside the fpga. The data sheet will tell you how fast things can go. I have just had a look on Xilinx and there is an app note called Virtex-5 FPGA Interface to a JESD204A Compliant ADC It looks like you can use Rocket IO if your ADC is compliant to JESD204A standard. But as you have LVDS signals then you cant use this method. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152077
Hi, I know this isn't the right place to ask this question, but since i use this forum frequently, i thought i should start from here. Has anybody here worked on Ericsson's Eurocom D1 protocol ? I need some help about it. Thanks a lot Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152078
The data rate is rather low. 640ksps at 16 bits is only 12.8MBbps. You can have one chip for each ADC, daisy chained to create one common bitstream from all the sources. This can be accomplished in very small FPGAs or in a CPLDs. With the right protocol you could also use a microcontroller. The last chip can send this data using any technology that can provide this bitrate at the desired distance. You can either use standard hardware and protocols (eg. ethernet or one of the DSL variants) or given the simple application you can roll your own protocol using a phy for one of these technologies. If you build only one of these, microcontrollers with ADC interfaces and ethernet that connect to an SDSL-Modem are probably the easiest to do. Kolja cronologicArticle: 152079
On Jun 30, 6:08=A0pm, "jgk2004" <john.kauffman@n_o_s_p_a_m.n_o_s_p_a_m.uni-ulm.de> wrote: > Hello Jon, > > You are completely correct, =A0I do not understand the virtex 5 at all!! > What guide(since there are like 10) would you recommend reading to learn > about LVDS. =A0Thank god i pinned out almost everything on my PCB to > headers... just need to make a new socket board! > > Thanks > > Jgk > > > > >It seem to me as though you dont really understand the Virtex 5 > >architecture. You need to read the user guide and data sheet to get a > feel > >what is possible with a certain IO technology. Rocket IO uses CML type > >drivers which are different to LVDS. LVDS upto 1.25 Gb/s is possible. > > >Jon =A0 =A0 > > >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 > >Posted throughhttp://www.FPGARelated.com > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Go through the Virtex-5 user guide i.e. UG190. There is a detailed chapter on SelectIO (Chapter 6) which will help you in serialization/ de-serialization of your 250MHz LVDS lines. One important point to be noted here is that GTPs won't work at lower frequencies (You need to use the oversampling circuitry available in GTPs) like 250 MHz in your case. . Anyway GTPs work with HSTL standard which is different from LVDS.Article: 152080
On 6/5/2011 10:53 AM, Mike Treseler wrote: > Your choices are: > 1. Buy a license and write vhdl procedures for the verilog uut. > 2. Learn verilog and write a verilog testbench. > 3. Write your own phy model in vhdl. > I believe there's a forth. Since the model "has already been tested deeply" I would create the vhdl model out of the back annotation that it certainly has (I used to do that with Designer for Actel devices). Once you have your PHY_ba.vhd you simply include it in your simulation and you instantiate it in your testbench as you would do normally with a component written in vhdl. If your PHY model never went through a post-layout simulation I hardly doubt it was "tested deeply" and I would seriously reconsider the first three options listed by Mike. AlArticle: 152081
Brian Drummond <brian@shapes.demon.co.uk> writes: > Also it's good to know that both parsers are available in case of trouble. > Only for (some - V5 and S3 I think) old devices - AFAIK from 6-devices onwards it's the new parser only. >> Apparently it's the default if you're using newer devices, though I >> haven't investigated that in detail. I'm using a heritage Spartan-3. >> >> Problem solved, job done, happy customer. > > And if newer really = better, then kudos to the XST team. > So far it has been IME... > I haven't got around to trying out my carefully cultivated nest of vipers > on ISE13 yet. > Do let us know how you fare :) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 152082
Rob Gaddi wrote: > Offhand, it seems like if you managed 12 bits it'd be a miracle. Even > if you stabilized the power supply voltages (and had zero ground bounce > induced by the rest of the logic), it seems like you'd need rise/fall > symmetry into the femtoseconds on the digital outputs in order to not > shoot your linearity. There is a paper which states that they can do 24 bit: http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/dac_fpt03.pdf But I didn't found a description of the output stage. They measured -112 dB THD+N, but I don't think with all the noise on the supply voltages of a FPGA that they drive a RC filter directly. -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbussArticle: 152083
Hi need to implement a bidirectional 8 bit interface of a FPGA with a microcontroller. For now i am developing with a Ciclone II but i will have to make it for a Spartan-3A too. Inside the FPGA i have 2 fifos one that will hold the data that i will wire to the uC and on the other i have to put the data that the uC sends to FPGA. The communication is controlled by the uC, so there will be a we pin to set the pins direction.. a 8 bit birectional data bus, a data_rdy pin to tell uC that there is data availabe on the FIFO, and a "clk" pin. I mean clock becouse it wont be a continuously clock. Just something like on every posedge the data will be sampled on FPGA (if we is asserted) or the FPGA will change the the output (if we is not asserted). On the FPGA there will be a 50Mhz clock. I am implementing both fifos using altera megafuntion (and probably the same will be done with Xilinx FPGA). I have a few questions. First will this code works to control the port direction? Or it should be clocked? module bidir_port ( out_en, data_in, data_out, port ); input out_en; input [7:0] data_in; output [7:0] data_out; inout [7:0] port; assign port = out_en ? data_out : 8'bz; assign data_in = port; endmodule; Second, i have two options to create this communication. First, to use the communication control pin to clock the FIFOs, but i dont know if need to use a constiguously clock on FIFOs ... The other option would be to synchronize all the signals to FPGA 50Mhz, and create a pulse on the wt_en and rd_en port of fifos on every edge of the uC ctrol pin. Will both work? Anything i should pay attention? Thank you!!Article: 152084
>>If you build only one of these, microcontrollers with ADC interfaces >and ethernet that connect to an SDSL-Modem are >probably the easiest to do. > >Kolja >cronologic > > > > > > Thanks for your reply.I have searched SDSL modems on internet but i could not find any modem that can be fitted in 50mm diameter pipe.If you have seen any such modem kindly share it. Thanks Best Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152085
>Hi need to implement a bidirectional 8 bit interface of a FPGA with a >microcontroller. For now i am developing with a Ciclone II but i will >have to make it for a Spartan-3A too. > >Inside the FPGA i have 2 fifos one that will hold the data that i will >wire to the uC and on the other i have to put the data that the uC >sends to FPGA. The communication is controlled by the uC, so there >will be a we pin to set the pins direction.. a 8 bit birectional data >bus, a data_rdy pin to tell uC that there is data availabe on the >FIFO, and a "clk" pin. I mean clock becouse it wont be a continuously >clock. Just something like on every posedge the data will be sampled >on FPGA (if we is asserted) or the FPGA will change the the output (if >we is not asserted). On the FPGA there will be a 50Mhz clock. I am >implementing both fifos using altera megafuntion (and probably the >same will be done with Xilinx FPGA). I have a few questions. First >will this code works to control the port direction? Or it should be >clocked? > >module bidir_port ( > out_en, > data_in, > data_out, > port > ); > >input out_en; >input [7:0] data_in; >output [7:0] data_out; >inout [7:0] port; > >assign port = out_en ? data_out : 8'bz; >assign data_in = port; > >endmodule; > >Second, i have two options to create this communication. First, to >use the communication control pin to clock the FIFOs, but i dont know >if need to use a constiguously clock on FIFOs ... The other option >would be to synchronize all the signals to FPGA 50Mhz, and create a >pulse on the wt_en and rd_en port of fifos on every edge of the uC >ctrol pin. > >Will both work? Anything i should pay attention? > >Thank you!! > The code snippet you posted, it has some errors. Have you tried synthesizing it? You already have a bidirectional port for communication between uC and FPGA so you don't need to declare data_in and data_out as in/out . Declare them as simple wires and use them wherever you want to use them. Secondly, if i were you, i'd prefer to sync all the signals to FPGA's 50Mhz clock and create a pule on wr_en / rd_en signals. Btw, you will write data to uC when rd_en will be asserted, right ? In that case, your tri-state condition will be assign port = rd_en ? data_port : 8'hzz; --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152086
On Jul 3, 6:08=A0am, "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > >Hi need to implement a bidirectional 8 bit interface of a FPGA with a > >microcontroller. For now i am developing with a Ciclone II but i will > >have to make it for a Spartan-3A too. > > >Inside the FPGA i have 2 fifos one that will hold the data that i will > >wire to the uC and on the other i have to put the data that the uC > >sends to FPGA. The communication =A0is controlled by the uC, so there > >will be a we pin to set the pins direction.. a 8 bit birectional data > >bus, a data_rdy pin to tell uC that there is data availabe on the > >FIFO, =A0and a "clk" pin. I mean clock becouse it wont be a continuously > >clock. Just something like on every posedge the data will be sampled > >on FPGA (if we is asserted) or the FPGA will change the the output (if > >we is not asserted). On the FPGA there will be a 50Mhz clock. I am > >implementing both fifos using altera megafuntion (and probably the > >same will be done with Xilinx FPGA). I have a few questions. First > >will this code works to control the port direction? Or it should be > >clocked? > > >module bidir_port ( > > =A0 =A0out_en, > > =A0 =A0data_in, > > =A0 =A0data_out, > > =A0 =A0port > > =A0 =A0); > > >input =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_en; > >input =A0 =A0 =A0 =A0 =A0 =A0 =A0 [7:0] =A0 data_in; > >output =A0 =A0 =A0[7:0] =A0 data_out; > >inout =A0 =A0 =A0 =A0 =A0 =A0 =A0 [7:0] =A0 port; > > >assign =A0 =A0 =A0port =3D out_en ? data_out : 8'bz; > >assign =A0 =A0 =A0data_in =3D port; > > >endmodule; > > >Second, i =A0have two options to create this communication. First, to > >use the communication control pin to clock the FIFOs, but i dont know > >if need to use a constiguously clock on FIFOs ... The other option > >would be to synchronize all the signals to FPGA 50Mhz, and create a > >pulse on the wt_en and rd_en port of fifos on every edge of the uC > >ctrol pin. > > >Will both work? Anything i should pay attention? > > >Thank you!! > > The code snippet you posted, it has some errors. Have you tried > synthesizing it? You already have a bidirectional port for communication > between uC and FPGA so you don't need to declare data_in and data_out as > in/out . Declare them as simple wires =A0and use them wherever you want t= o > use them. > > Secondly, if i were you, i'd prefer to sync all the signals to FPGA's 50M= hz > clock and create a pule on wr_en / rd_en signals. > > Btw, you will write data to uC when rd_en will be asserted, right ? In th= at > case, your tri-state condition will be > > assign port =3D rd_en ? data_port : 8'hzz; > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Hahaha, about the in and out signals.. thats just the signals inside the FPGA becouse i was creating a generic module for a bidirectional port, it is a waste of lines, but would be easier to change .... anyway, just to know, why do you say that to sync the signal is better? Will i have any problem to clock a DPRAM with a non-contiguous signal? Thank you!Article: 152087
Hi all Can any one kindly tell me from where i can get small size (atleast width < 50mm) SDSL modem with ethernet input? Best Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152088
Normally, the tools check that there are no driver conflicts during synthesis and shut down all drivers when start the configuration. Yet, one and the same line can be driven by different drivers in different designs. And, no logic is shut down in dynamic reconfiguration. I see that it is possible therefore that the new driver is connected to line before the old one is released. This is a short! How do they detect and avoid this? Hardly, user can do this. Xilinx seems unable to answer that question http://forums.xilinx.com/t5/Hierarchical-Design/How-active-reconfiguration-is-possible/td-p/146856 and their active reconfiguration does not work. http://forums.xilinx.com/t5/Hierarchical-Design/How-large-the-diff-based-reconfiguration-can-be/td-p/157134Article: 152089
On 07/02/2011 05:21 PM, Sink0 wrote: > Hi need to implement a bidirectional 8 bit interface of a FPGA with a > microcontroller. For now i am developing with a Ciclone II but i will > have to make it for a Spartan-3A too. > > Inside the FPGA i have 2 fifos one that will hold the data that i will > wire to the uC and on the other i have to put the data that the uC > sends to FPGA. The communication is controlled by the uC, so there > will be a we pin to set the pins direction.. a 8 bit birectional data > bus, a data_rdy pin to tell uC that there is data availabe on the > FIFO, and a "clk" pin. I mean clock becouse it wont be a continuously > clock. Just something like on every posedge the data will be sampled > on FPGA (if we is asserted) or the FPGA will change the the output (if > we is not asserted). If you do that, then you'll (most likely) write out multiple bytes on a read from your device, and read in multiple identical bytes from a write to your device. You want to detect the rising edge of the write enable and pop _one_ byte from your FPGA's outward-bound FIFO. Similarly, you want to detect the rising edge of your read enable and push _one_ byte into your inward-bound FIFO. > On the FPGA there will be a 50Mhz clock. I am > implementing both fifos using altera megafuntion (and probably the > same will be done with Xilinx FPGA). I have a few questions. First > will this code works to control the port direction? Or it should be > clocked? If you can meet the microprocessor's setup and hold time while clocking the port from your FPGA clock, then that's the way to go. Synchronous is nearly always better than asynchronous -- to the point where, if you have to ask, you should assume that it should be synchronous. > > module bidir_port ( > out_en, > data_in, > data_out, > port > ); > > input out_en; > input [7:0] data_in; > output [7:0] data_out; > inout [7:0] port; > > assign port = out_en ? data_out : 8'bz; > assign data_in = port; > > endmodule; > > Second, i have two options to create this communication. First, to > use the communication control pin to clock the FIFOs, but i dont know > if need to use a constiguously clock on FIFOs ... The other option > would be to synchronize all the signals to FPGA 50Mhz, and create a > pulse on the wt_en and rd_en port of fifos on every edge of the uC > ctrol pin. If you are using a memory port on the microprocessor, then there will be a timing diagram in the microprocessor data sheet that details its operation. Take that timing diagram and copy it out, then finish it with the pertinent internal signals of the FPGA. Calculate where all the edges may land (remember that if you're clocking the port from a 50MHz clock that's asynchronous to the micro that you have to treat the FPGA clock edges as being uncertain to +/- 10us). If you are bit-banging the exchange, and you have the pins available, then the timing diagram is your responsibility -- but you should still draw it out; in particular you should make sure that the read and write pulses out of the micro are long enough that the FPGA reliably catches the edges. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 152090
On Jul 4, 4:55=A0am, valtih1978 <d...@not.email.me> wrote: > Normally, the tools check that there are no driver conflicts during > synthesis and shut down all drivers when start the configuration. Yet, > one and the same line can be driven by different drivers in different > designs. And, no logic is shut down in dynamic reconfiguration. I see > that it is possible therefore that the new driver is connected to line > before the old one is released. This is a short! How do they detect and > avoid this? Hardly, user can do this. > > Xilinx seems unable to answer that questionhttp://forums.xilinx.com/t5/Hi= erarchical-Design/How-active-reconfigur... > > and their active reconfiguration does not work.http://forums.xilinx.com/t= 5/Hierarchical-Design/How-large-the-diff-ba... Yes, there will be momentary contention during partial reconfiguration. The duration is not long to cause damage to the device. Ed McGettigan -- Xilinx Inc.Article: 152091
> Yes, there will be momentary contention during partial > reconfiguration. =A0The duration is not long to cause damage to the > device. What happens if the source controller of the configuration update (internal or external to the chip) crashes/hangs/pauses in the middle of a reconfiguration? Wouldn't that potentially extend a momentary contention into a more long term contention? If that is able to cause damage to the device, then it would be advisable to specify a minimum reconfiguration speed. (I haven't checked whether such a specification is already present in the datasheets). Marc PS: I did runtime reconfiguration on an ATMEL AT94 part once, and found issues with contention as well. My workaround was to "idle" the chip with an "almost empty" bitstream first, and then repeat reconfiguration with the new target bitstream. The temporary bitstream contained nothing but I/O definitions to drive sane levels to the peripherials on the PCB.Article: 152092
On Jul 5, 8:44=A0am, Marc Jet <jetm...@hotmail.com> wrote: > > Yes, there will be momentary contention during partial > > reconfiguration. =A0The duration is not long to cause damage to the > > device. > > What happens if the source controller of the configuration update > (internal or external to the chip) crashes/hangs/pauses in the middle > of a reconfiguration? =A0Wouldn't that potentially extend a momentary > contention into a more long term contention? > > If that is able to cause damage to the device, then it would be > advisable to specify a minimum reconfiguration speed. =A0(I haven't > checked whether such a specification is already present in the > datasheets). > > Marc > > PS: =A0I did runtime reconfiguration on an ATMEL AT94 part once, and > found issues with contention as well. =A0My workaround was to "idle" the > chip with an "almost empty" bitstream first, and then repeat > reconfiguration with the new target bitstream. =A0The temporary > bitstream contained nothing but I/O definitions to drive sane levels > to the peripherials on the PCB. The time to failure will be highly dependent on the exact resources that are in contention and the reliability factors for those resources. There will always be pathological cases that can be contrived or created that will accelerate time to failure, so there isn't a single number that can be specified. If the reconfiguration "failed" it would (or should) generate a system reset and reconfiguration. Either automatically or by human interaction because the system is down. A few drivers in contention for hours or days won't be a problem. If it was expected to be even a minor risk then we would have a completely different partial reconfiguration methodology. If it is a big concern then an empty bitstream could be loaded first before the new design bitstream. Ed McGettigan -- Xilinx Inc.Article: 152093
> PS: I did runtime reconfiguration on an ATMEL AT94 part once, and > found issues with contention as well. My workaround was to "idle" the > chip with an "almost empty" bitstream first, and then repeat > reconfiguration with the new target bitstream. The temporary > bitstream contained nothing but I/O definitions to drive sane levels > to the peripherials on the PCB. On Xilinx v2p, even this workaround does not help (see refs).Article: 152094
On 7/2/2011 11:15 AM, Frank Buss wrote: > Rob Gaddi wrote: > >> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even >> if you stabilized the power supply voltages (and had zero ground bounce >> induced by the rest of the logic), it seems like you'd need rise/fall >> symmetry into the femtoseconds on the digital outputs in order to not >> shoot your linearity. > > There is a paper which states that they can do 24 bit: > > http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/dac_fpt03.pdf > > But I didn't found a description of the output stage. They measured -112 > dB THD+N, but I don't think with all the noise on the supply voltages of > a FPGA that they drive a RC filter directly. > God bless academics: "In order to debug the system in a noise free environment, we used an Agilent 16702B Logic analysis system to measure the output different bit-width and order settings. The state mode sampling method is chosen for synchronous sampling clocked by the FPGA board itself so that the exact output of the DAC can be captured by the logic analyzer." i.e. Measurements were taken to confirm that we get a stream of ones and zeros that we can assume to be perfect rectangles framed by a perfect clock. One day, we hope to use this to generate an analog waveform that we expect to have characteristics. Can't imagine why I decided not to go for that PhD. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 152095
On Jun 27, 1:08=A0pm, Alessandro Basili <alessandro.bas...@cern.ch> wrote: > I want to say that I'm on your side when you say that a "command-line" > use of FPGA tools is a nice to have, but I have to admit that the > overall tendency is to use GUI and integrated environments where the > designer has the (deceived) perception that everything is at his own > hand and control. > > We can argue a lifetime on what is better, but IMHO the market has > chosen its horse and is not the command-line, regardless efficiency > drawbacks. I understand that we do agree that scripted flows are better, so there's no need to argue. My view is that that horse is running out of steam in the face of progress in development methods and complexity. I'm not saying "nice to have", I'm saying that scripted flows are *essential* if we want to adopt any of the good stuff that software development has benefited from in the past decade. I'm talking about revision control, transparent IP/code reuse and distribution, modularity, team-based design, and so on. I also don't think it's the "market" that's made a choice, it's the vendors that have bet on the wrong horse. I've elaborated on this a bit here: https://www.boldport.com/blog/?p=3D369 > The portability problem is often used as an argument to propose yet > another model that will have eventually the same problems of portability > that previous models had. That is why I always intend portability in the > sense that is easy to carry around for it doesn't depend on system's > features or device's features and ultimately tool's features. That's a separate issue of generic vs architecture-specific design, which I've not gotten into in the context of the structure I'm proposing. Or, rather, I'm not arguing for either side. > In addition I believe most of the designers out there are not really > moving from a linux machine to a windows machine every day and they > don't switch from an ABC device to a CBA device every other day and > whenever they would be in the place where they *have to* switch, it's > going to be a hard day and no magic can be at hand but a previously > thought through approach to design in an as abstract way as possible. > > Hardware Description Languages have been invented for good because they > give the designer a mean which will help him looking at the big picture > instead of the gates and flops actually used. And this level of > abstraction has an enormous potential that most of the time is > overlooked in the names of concepts like "optimization" or "I had to put > that GCLK buffer otherwise it wouldn't work!". OK. > Talking about scalability problems, how do you intend to provide help on > the long run? Say you have 10 million users instead of 10, I think > numbers do play a difference. They sure do. 10 million is about two orders of magnitude off from my rough estimate for the potential user space. But the answer is that I don't know... I'll first deal with 10, then 100 and then see how things go. > On top of it, what make your company different from yet another EDA > company willing for designers to adopt their approach and strangle them > with incompatibility features that will shackle them for the rest of > their life? I'm conscious of this, and am doing my best to minimise lock-in, now and for the future (see here: https://www.boldport.com/blog/?p=3D103 ). Of course, there's a certain investment of resources in learning / adopting anything -- my hope is that what I'm proposing / offering has enough benefit for people to make that investment. Maybe I'm wrong; I'm testing my hypothesis right now. > Since is not open-source and is profit oriented, do you think it's > enough to say that your approach "is better" to convince designers to > change their habits? No; that's why I've written that long document. I tried to provide reasoning behind every choice I made, hoping to get feedback and revise as needed. > After all a designer wants to design as much as a painter wants to > paint. If art can be made with any tool available in your garage, > hardware can follow the same line and be built with just an editor or > any available tool you have in your computer (maybe a text editor is > enough!). Yes. > That is why IMHO we should foster good designing approaches that will > enhance the portability in terms of code, as opposed to project structure= . I don't see a reason why we can't have both. > The project approach is borrowed from the management world and has > nothing to do with HDL. Indeed I always asked myself why should I create > a project when my goal is to describe how a piece of hardware should > work. "Project" is a name poorly defined, a concept poorly defined, with > no boundaries and no constraints and that is the root of all your and > our problems. :) > > Thanks for your attention, > > Believe me, even though I might have sounded harsh, I paid a lot of > attention to it! Your feedback is greatly appreciated! I'm happy to continue this discussion here or privately.Article: 152096
On Jul 6, 5:09=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote: > > God bless academics: > Yes, I love the -250dB noise floors on the plots, which (of course) are simulated. and real measurements, are entirely optional, 'we'll get to that later' !! ["An Audio Precision System Two Cascade audio analyzer with -112dB THD +N for a 20kHz input will be used to further verify the system and results will be presented at the conference."] - but yes, in the real world, you can build 24b calibration DACs, using an external element for the 1 bit DAC.Article: 152097
Well i am trying to do the very same thing but i am having problems in writing the user_logic file as i am accustomed only to verilog. Even in verilog the custom_core.vhd file is in VHDL. I am having problems if any one can guide me on that. How should i manage, i have already put two registers in the core, one for reading data and other for writing. Now can u guide me in configuring it so that it can read and write data.(verilog part)Article: 152098
>Well i am trying to do the very same thing but i am having problems in writing the user_logic file as i am accustomed only to verilog. Even in verilog the custom_core.vhd file is in VHDL. I am having problems if any one can guide me on that. > >How should i manage, i have already put two registers in the core, one for reading data and other for writing. > >Now can u guide me in configuring it so that it can read and write data.(verilog part) > When you generate a custom core in EDK, set the check box to create a Verilog template for the user logic. You can then write your logic in Verilog. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152099
That means you have over cooked it ... turn down the temp a bit next time. On Jun 29, 11:46=A0am, "chifalcon" <eric.he@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com> wrote: > Hi, > =A0 I implemented a full combinatinal logic in Xilinx FPGA. A white and b= lack > eye appears on each SLICE. What does it means?? > > =A0 Thanks =A0 =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com
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