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
=E5=9C=A8 2013=E5=B9=B411=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94UTC=
+8=E4=B8=8B=E5=8D=888=E6=97=B630=E5=88=8659=E7=A7=92=EF=BC=8Cbaum=E5=86=99=
=E9=81=93=EF=BC=9A
> Hi,
>=20
>=20
>=20
> I try to implement a DDR3 hard memory controller in a Cyclone v device
>=20
> a 5CGXFC3B6F23C7.
>=20
>=20
>=20
> I created an DDR3 hard memory controller IP core with the Megawizard,=20
>=20
> integrated the core in my design and added my design files in Quartus.
>=20
>=20
>=20
> The fitter of Quartus gives following error message
>=20
>=20
>=20
> Error (15332): Port SHIFTEN of cyclonev_pll_reconfig
>=20
> "HeadTop:I_HeadTop|DDR3Controller:I_MemCtrlBlk|Ddr3MemCtrl:Ddr3MemCtrl_1|=
Ddr3MemCtrl_000=20
>=20
>=20
>=20
> 2:ddr3memctrl_inst|Ddr3MemCtrl_pll0:pll0|pll1~PLL_RECONFIG" has 11=20
>=20
> connections, but the maximum
>=20
> bus width of port SHIFTEN is 9
>=20
>=20
>=20
> In the file Ddr3MemCtrl_pll0 there are 11 generic_pll instances and as=20
>=20
> far as I know the Cyclone Pll has only 9 clock outputs so I assume the=20
>=20
> error message refers to this and barks about the two additional clock=20
>=20
> outputs.
>=20
>=20
>=20
> In the Megawizard there is no switch to select the number of clock=20
>=20
> outputs of the hard memory controller.
>=20
>=20
>=20
> I tried to synthesise the example created by the Megawizard, but the=20
>=20
> funny thing is this example is not for the Cyclone V device I specified=
=20
>=20
> in Quartus and the fitter ends with an error message too.
>=20
> This time not about the Pll but about some errors with output pins.
>=20
>=20
>=20
> So my question is:
>=20
> Has anybody implemented successfully a design with a DDR3 hard memory=20
>=20
> controller in a Cyclone v device or stumbled on the same error message=20
>=20
> as above.
>=20
>=20
>=20
> Btw. I use Quartus 13.1 according to Altera the latest version but IMHO=
=20
>=20
> not the greatest.
>=20
>=20
>=20
> Robert
Hi,Robert=20
Did you resolve this problem? I also meet it in 5CGXFC5C6F23C7N with Q=
uartus 13.1.My QSYS used clock bridge and mm bride.if ddr3.av0 is connected=
with mm bridge or ddr3.av0 is connected with cpu data,this error will happ=
en.There is no error in Quartus 13.0.
Article: 156376=E5=9C=A8 2013=E5=B9=B411=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94UTC= +8=E4=B8=8B=E5=8D=888=E6=97=B630=E5=88=8659=E7=A7=92=EF=BC=8Cbaum=E5=86=99= =E9=81=93=EF=BC=9A > Hi, >=20 >=20 >=20 > I try to implement a DDR3 hard memory controller in a Cyclone v device >=20 > a 5CGXFC3B6F23C7. >=20 >=20 >=20 > I created an DDR3 hard memory controller IP core with the Megawizard,=20 >=20 > integrated the core in my design and added my design files in Quartus. >=20 >=20 >=20 > The fitter of Quartus gives following error message >=20 >=20 >=20 > Error (15332): Port SHIFTEN of cyclonev_pll_reconfig >=20 > "HeadTop:I_HeadTop|DDR3Controller:I_MemCtrlBlk|Ddr3MemCtrl:Ddr3MemCtrl_1|= Ddr3MemCtrl_000=20 >=20 >=20 >=20 > 2:ddr3memctrl_inst|Ddr3MemCtrl_pll0:pll0|pll1~PLL_RECONFIG" has 11=20 >=20 > connections, but the maximum >=20 > bus width of port SHIFTEN is 9 >=20 >=20 >=20 > In the file Ddr3MemCtrl_pll0 there are 11 generic_pll instances and as=20 >=20 > far as I know the Cyclone Pll has only 9 clock outputs so I assume the=20 >=20 > error message refers to this and barks about the two additional clock=20 >=20 > outputs. >=20 >=20 >=20 > In the Megawizard there is no switch to select the number of clock=20 >=20 > outputs of the hard memory controller. >=20 >=20 >=20 > I tried to synthesise the example created by the Megawizard, but the=20 >=20 > funny thing is this example is not for the Cyclone V device I specified= =20 >=20 > in Quartus and the fitter ends with an error message too. >=20 > This time not about the Pll but about some errors with output pins. >=20 >=20 >=20 > So my question is: >=20 > Has anybody implemented successfully a design with a DDR3 hard memory=20 >=20 > controller in a Cyclone v device or stumbled on the same error message=20 >=20 > as above. >=20 >=20 >=20 > Btw. I use Quartus 13.1 according to Altera the latest version but IMHO= =20 >=20 > not the greatest. >=20 >=20 >=20 > Robert The same error will be happend when I tested it with DDR3 soft controller.Article: 156377
Hi Jim, Jim Lewis <usevhdl@gmail.com> wrote: [] >> I've found a third option which might be quite interesting >> especially when dealing with standard buses: [] > This is ok at a testbench level, but if you wanted to use it > inside your system, you will need to check and see if your synthesis > tool is tolerant of user defined resolution functions. I guess that's a kind of a lesson learned the hard way. I do not have as of now any working example that follows the option above mentioned, but if I manage to give it a try I'll post some results/impressions. > You will want to make sure that the error injector (on the > generation side) communicates with the checker (on the receiver > side) so that the checker knows it is expecting a particular type > of error. In addition, you will want your test case generator to > be able to initiate errors in a non-random fashion. Right. My idea was to use the 'error injector' as a /slave/ but I do not yet know how to connect it to my transaction generator (or whatever is the appropriate name for it). I may potentially use global signals, but I'm not a big fan of them since they tend to increase universe entropy drastically! In my framework I use two global records to communicate with the 'server' and I could in principle extend them to pass the information further along within the defective module. It is not entirely clean though, in fact the server cannot handshake with the defective module since it does not know it has been so configured. Well, we can imagine that if the global records elements are filled it is because the client wants to inject those errors, so the server can assume the defective module is in place and will handshake with it. Uhm, this is getting interesting... > For my testbenches, I like each BFM to be able to generate any > type of error that the DUT can gracefully handle. Then I set > up the transactions so they can communicate this information. > To randomly generate stimulus and inject errors, I use the > OSVVM randomization methods to do this at the test case generation > level (TestCtrl). And indeed the mechanism would work even if the BFM are encapsulated within internal components of the DUT and implement the error injection as suggested above. BTW I just put my hands on 'Comprehensive functional verification' Wile, Goss, Roesner, it's a 700 pages volume on the verification cycle, I guess it'll keep me busy for some time ;-) AlArticle: 156378
Hi Jim, Jim Lewis <usevhdl@gmail.com> wrote: [] >> I do not quite understand the reason to split testcases in separate >> architectures, I use to envelop the TbMemIO in what I call 'harness' and >> instantiate it in each of my testcases. The harness grows as BFMs become >> available and it never breaks an earlier testcase since the newly >> inserted BFM was not used in earlier testcases. > This separation is important for reuse at different level of testing. > Separate that test case from that models that implement the exact > interface behavior. The models can be implemented with either a > procedure in a package (for simple behaviors) or an entity and > architecture (for more complex models - this is what the paper I > referenced shows). I think I did not correctly phrased what I meant. I do understand the importance of testcases to be separate. I have my 'client/server' model in place, where my transaction happens between them and then the server implements each call with a specific low level transaction, involving the BFM for each interface. In this way my client may operate as long as the server interface is kept the same. What I did not understand in your paper was the 'need' of a separate architecture instead of a separate file with a new entity/architecture. The harness I referred to earlier is what instantiate the DUT and all the necessary BFMs, the client/server transaction happens with a pair of global records (to_srv_ctrl/fr_srv_ctrl) which handles the 'handshake' in the transaction. The harness grows as more BFMs become available and more interfaces are being implemented. >> Unfortunately cost and time are not yet available. I'd love to follow >> that course but as of now I need to rely on my own trials and >> guidance like yours ;-) > Do you work for free? If not, I suspect the cost of you learning by > reading, trial and error, and searching the internet when you run > into issues is going to cost much more than a class. You seem to be > progressing ok though. I'm used to learn by reading (and asking). On top of this, my actual job description does not require these skills...another reason for not being able to ask for such a course! But I'm not giving up ;-) AlArticle: 156379
Hi Al, Maybe this time I will answer the right question. :) > What I did not understand in your paper was the 'need' of a separate > architecture instead of a separate file with a new entity/architecture.= =20 There are two issues. The obvious one is having multiple copies of the sam= e entity can lead to maintenance issues if the interface changes.=20 The not so obvious is the impact of compile rules. Dependencies in VHDL ar= e on primary units (entity, package declaration, configuration declaration)= and not secondary design units (architecture or package body). =20 Lets assume the TestCtrl entity and architecture are in separate files and = I am not using configurations. I can compile my design and test hierarchy= and run test1. Now to run test2, all I need to do is compile test2 archit= ecture and I can restart the testbench and it runs (because the most recent= ly compiled architecture is selected). =20 Going further, when I add configurations, I can compile my design, test hie= rarchy, test1 architecture, and configuration1, and then run configuration1= . Then I can compile test2 architecture and configuration2, and then run c= onfiguration2. To re-run configuration1, all I need to do is select run co= nfiguration1. =20 On the other hand, if we put the entity in the same file as the architectur= e, then the process gets much harder. If you compile test1, since the enti= ty was recompiled, the testbench hierarchy above TestCtrl must also be reco= mpiled, then you can start a simulation. To run test2, again compile test2= and the testbench hierarchy above TestCtrl, and then start a simulation. = Configuration declarations would require this same compile extensive proce= ss.=20 I note some simulators work around some of this stuff with switches and aut= omatically. With switches works well, but is tedious. Automatically works= most of the time, but from time to time it does not and that makes for deb= ug sessions in which you are chasing a nonexistent problem. =20 Hope I answered the right question this time. =20 Cheers, JimArticle: 156380
On Thursday, March 20, 2014 1:41:55 AM UTC-7, Carl wrote: > Hi, >=20 > =20 >=20 > I'm having some problems to understand the exact behavior of the ISERDESE= 2 primitive. What I need to understand is exactly how the unit will distrib= ute the serial input to the bits in the output (paralell) words, or in othe= r words, how ISERDESE aligns the frames on the incoming serial data stream = in order to deliver the paralell words. >=20 > =20 >=20 > Here is a screenshot showing the signals on some of the ports of a cascad= ed (width expansion) ISERDES-pair: >=20 > http://forums.xilinx.com/t5/image/serverpage/image-id/11986i790019220C796= 0F0/ >=20 >=20 >=20 > This example is actually from a simulation of the example design that is = generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mod= e. The VHDL file can be downloaded here: >=20 > http://forums.xilinx.com/xlnx/attachments/xlnx/7Series/3904/2/selectio_if= _wiz_v4_1.zip >=20 > =20 >=20 > The signal iserdes_q_vec is a vector [slave q8..q3] & [master q8..q1]. >=20 > =20 >=20 > From the input (ddly) and output (iserdes_q_vec) I can clearly see how th= e frame is aligned - I have marked the frame by the two cursors. It is clea= r that the ddly input within this frame (10000111100100) is what appears on= iserdes_q_vec on the next rising edge of clkdiv. >=20 > =20 >=20 > The reason for this particular alignment is however unknown to me. I've l= ooked in the User Guide (ug471) but can't find info on this. >=20 > =20 >=20 > I tried to de-assert rst in various ways but couldn't really make anythin= g out of the results (in this design, rst is de-asserted synchronously with= clkdiv, as suggested by the user guide). >=20 > =20 >=20 > In my case, I have no training pattern and hance can't find the right ali= gnment with bitslip operations. In my case, for the serial data, clkdiv is = equal to the frame clock. From the simulation I can of course determine how= the frame is placed in the serial data, and fix the paralell words in cust= om logic, but then I need to understand why I get this particular offset, a= nd be convinced that I will always get exactly this particular offset. >=20 > =20 >=20 > I would intuitively have expected clkdiv to act as a frame clock as well,= but nothing in the UG suggests that, and according to the simulation, that= is also clearly not the case. >=20 > =20 >=20 > Device: xc7k160t-2 >=20 > =20 >=20 > Thanks in advance, >=20 > Carl I don't think you can rely on the real hardware presenting the parallel wor= d in any particular bit alignment or offset. You will want to add a trainin= g sequence that is run at startup to bitslip the iserdes appropriately, and= then turn the interface lose for general traffic.Article: 156381
matt.lettau@gmail.com wrote: > On Thursday, March 20, 2014 1:41:55 AM UTC-7, Carl wrote: >> Hi, >> >> >> >> I'm having some problems to understand the exact behavior of the ISERDESE2 primitive. What I need to understand is exactly how the unit will distribute the serial input to the bits in the output (paralell) words, or in other words, how ISERDESE aligns the frames on the incoming serial data stream in order to deliver the paralell words. >> >> >> >> Here is a screenshot showing the signals on some of the ports of a cascaded (width expansion) ISERDES-pair: >> >> http://forums.xilinx.com/t5/image/serverpage/image-id/11986i790019220C7960F0/ >> >> >> >> This example is actually from a simulation of the example design that is generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mode. The VHDL file can be downloaded here: >> >> http://forums.xilinx.com/xlnx/attachments/xlnx/7Series/3904/2/selectio_if_wiz_v4_1.zip >> >> >> >> The signal iserdes_q_vec is a vector [slave q8..q3] & [master q8..q1]. >> >> >> >> From the input (ddly) and output (iserdes_q_vec) I can clearly see how the frame is aligned - I have marked the frame by the two cursors. It is clear that the ddly input within this frame (10000111100100) is what appears on iserdes_q_vec on the next rising edge of clkdiv. >> >> >> >> The reason for this particular alignment is however unknown to me. I've looked in the User Guide (ug471) but can't find info on this. >> >> >> >> I tried to de-assert rst in various ways but couldn't really make anything out of the results (in this design, rst is de-asserted synchronously with clkdiv, as suggested by the user guide). >> >> >> >> In my case, I have no training pattern and hance can't find the right alignment with bitslip operations. In my case, for the serial data, clkdiv is equal to the frame clock. From the simulation I can of course determine how the frame is placed in the serial data, and fix the paralell words in custom logic, but then I need to understand why I get this particular offset, and be convinced that I will always get exactly this particular offset. >> >> >> >> I would intuitively have expected clkdiv to act as a frame clock as well, but nothing in the UG suggests that, and according to the simulation, that is also clearly not the case. >> >> >> >> Device: xc7k160t-2 >> >> >> >> Thanks in advance, >> >> Carl > > I don't think you can rely on the real hardware presenting the parallel word in any particular bit alignment or offset. You will want to add a training sequence that is run at startup to bitslip the iserdes appropriately, and then turn the interface lose for general traffic. Which really sucks when you have no training pattern as noted in the OP. In the past, I've used DDR registers instead of ISERDES in cases where there was no way to have a training pattern. However I never needed to do this above 585 Mbps. In my case I was doing Camera Link (7:1 serial with 1x word clock), and I "deserialized" the clock to get a framing signal. It might be possible to do the same with ISERDES, if you can relay on multiple ISERDES to come up in the same phase each time. Then applying the same number of bitslips to all ISERDES (including the one "deserializing" the clock) should allow you to find the right alignment by applying bitslip until the deserialized clock has the right phase (1100011 for Camera Link). -- GaborArticle: 156382
Den fredag den 21. marts 2014 20.44.37 UTC+1 skrev Gabor: > matt.lettau@gmail.com wrote: >=20 > > On Thursday, March 20, 2014 1:41:55 AM UTC-7, Carl wrote: >=20 > >> Hi, >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> I'm having some problems to understand the exact behavior of the ISERD= ESE2 primitive. What I need to understand is exactly how the unit will dist= ribute the serial input to the bits in the output (paralell) words, or in o= ther words, how ISERDESE aligns the frames on the incoming serial data stre= am in order to deliver the paralell words. >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> Here is a screenshot showing the signals on some of the ports of a cas= caded (width expansion) ISERDES-pair: >=20 > >> >=20 > >> http://forums.xilinx.com/t5/image/serverpage/image-id/11986i790019220C= 7960F0/ >=20 > >> >=20 > >> >=20 > >> >=20 > >> This example is actually from a simulation of the example design that = is generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR = mode. The VHDL file can be downloaded here: >=20 > >> >=20 > >> http://forums.xilinx.com/xlnx/attachments/xlnx/7Series/3904/2/selectio= _if_wiz_v4_1.zip >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> The signal iserdes_q_vec is a vector [slave q8..q3] & [master q8..q1]. >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> From the input (ddly) and output (iserdes_q_vec) I can clearly see how= the frame is aligned - I have marked the frame by the two cursors. It is c= lear that the ddly input within this frame (10000111100100) is what appears= on iserdes_q_vec on the next rising edge of clkdiv. >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> The reason for this particular alignment is however unknown to me. I'v= e looked in the User Guide (ug471) but can't find info on this. >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> I tried to de-assert rst in various ways but couldn't really make anyt= hing out of the results (in this design, rst is de-asserted synchronously w= ith clkdiv, as suggested by the user guide). >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> In my case, I have no training pattern and hance can't find the right = alignment with bitslip operations. In my case, for the serial data, clkdiv = is equal to the frame clock. From the simulation I can of course determine = how the frame is placed in the serial data, and fix the paralell words in c= ustom logic, but then I need to understand why I get this particular offset= , and be convinced that I will always get exactly this particular offset. >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> I would intuitively have expected clkdiv to act as a frame clock as we= ll, but nothing in the UG suggests that, and according to the simulation, t= hat is also clearly not the case. >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> Device: xc7k160t-2 >=20 > >> >=20 > >> =20 >=20 > >> >=20 > >> Thanks in advance, >=20 > >> >=20 > >> Carl >=20 > >=20 >=20 > > I don't think you can rely on the real hardware presenting the parallel= word in any particular bit alignment or offset. You will want to add a tra= ining sequence that is run at startup to bitslip the iserdes appropriately,= and then turn the interface lose for general traffic. >=20 >=20 >=20 > Which really sucks when you have no training pattern as noted in the OP. >=20 > In the past, I've used DDR registers instead of ISERDES in cases where >=20 > there was no way to have a training pattern. However I never needed to >=20 > do this above 585 Mbps. In my case I was doing Camera Link (7:1 serial >=20 > with 1x word clock), and I "deserialized" the clock to get a framing >=20 > signal. It might be possible to do the same with ISERDES, if you can >=20 > relay on multiple ISERDES to come up in the same phase each time. Then >=20 > applying the same number of bitslips to all ISERDES (including the one >=20 > "deserializing" the clock) should allow you to find the right alignment >=20 > by applying bitslip until the deserialized clock has the right phase >=20 > (1100011 for Camera Link). >=20 I've done something similar for an AD9228 ADC, bitslip applied until the=20 deserialized frame clock shows the correct pattern =20 -LasseArticle: 156383
Hi, I'm looking for a vendor-independent solution to configure RAM contents on an FPGA without rebuilding the RTL. Is there such a thing? Xilinx has their proprietary data2mem interface that let me replace data in the bitstream file, but it requires a lot of "low-level" work to describe how the RAM is formed from primitives. What I'm looking for is a generic solution, in the same way as putting initial values into inferred RAM, but without having to recompile everything. I've built my own "homespun" loader using a hardware UART interface, i.e. some FTDI breakout board, and it works well enough within its limitations (extra gates, possibility of bus contention with the design). Now I was wondering, as this seems like such a common problem, is there any known "simple" way for this? JTAG maybe? I did some superficial search here but JTAG seemed to get quite complex, if I stay away from vendor-dependent tools. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156384
Hi, I'm looking for a high-speed PCI express example, like the one given in this video: https://www.youtube.com/watch?v=IOHgltR11QY&noredirect=1 but obviously my google-fu is failing me because I can't find an example matching the video. Does anyone have a DMA example as he shows, or something similar. I've been using Xillybus thus far, which is great but isn't useful for high-speed transfers. Advance thanks, Karol.Article: 156385
On Wednesday, 15 January 2014 11:37:04 UTC+5, Tim Wescott wrote: > On Sat, 11 Jan 2014 23:31:10 -0800, eyecatcherdear wrote: > Hi I have to = perform punctured convolution encoding at 3/4 rate on > Verilog. Can anyone= provide me the source code to perform puncturing? I > am able to perform c= onvolution coding. Don't know how to implement > puncturing on it.I have to= maintain an output data rate of 100 MHz. OK. It's not even close to April,= so this isn't an April fool's joke. What part of removing one of every fou= r bits are you having trouble with? -- Tim Wescott Wescott Design Services = http://www.wescottdesign.com haha..well actually i have performed puncturing..sorry for the incomplete p= ost.but that is at different output rate approach. I want to know if there = is method in which i can maintain same rate for input and output without ha= lting the data and just obtain a punctured code. Though my code works just= fine. I have PLL clock generation core limitation in my design. So the pro= blem arises.Article: 156386
I'm using virtex 5 ML506 board. I want to display image on monitor. Kit has DVI connections. So please tell me, is it necessary to program DVI using IIC? or It works with giving only data, sync signals, and clocks..Article: 156387
On Tuesday, March 25, 2014 12:27:04 AM UTC, Karol Hennessy wrote: > Hi, > > > > I'm looking for a high-speed PCI express example, like the one given in this video: > > > > https://www.youtube.com/watch?v=IOHgltR11QY&noredirect=1 > > > > but obviously my google-fu is failing me because I can't find an example matching the video. > > > > Does anyone have a DMA example as he shows, or something similar. I've been using Xillybus thus far, which is great but isn't useful for high-speed transfers. > > > > Advance thanks, > > Karol. Hi, Never heard of Xillybus before, so I was curious to take a look at it. Why is it not useful for high-speed transfers? Page 17 of this manual discusses high speed IO. I only skim read it, but it seems to discuss the relevant technique, mapping user space RAM as a DMA buffer. http://xillybus.com/downloads/doc/xillybus_host_programming_guide_linux.pdf RupertArticle: 156388
Hi Rupert, On his website, he says the limits are about 400 MB/s for most devices, which is nothing like the PCIe bandwidth (assuming you've more than one lane). http://xillybus.com/pcie-download The limitation seems to be due to the bus width/CPU overhead. The author explains it here: http://forum.xillybus.com/viewtopic.php?f=2&t=42 To talk to another device, I'll have to write my own driver I think. That's probably too much work for what I want so, I'll probably use some sort of high speed Gb connection. If you don't need warp-speed, I'd still recommend xillybus. It's extremely easy to use, even for a n00b like me. Thanks for the response, Karol. On Wednesday, 26 March 2014 09:35:10 UTC+1, rupert...@googlemail.com wrote: > On Tuesday, March 25, 2014 12:27:04 AM UTC, Karol Hennessy wrote: > > > Hi, > > > > > > > > > > > > I'm looking for a high-speed PCI express example, like the one given in this video: > > > > > > > > > > > > https://www.youtube.com/watch?v=IOHgltR11QY&noredirect=1 > > > > > > > > > > > > but obviously my google-fu is failing me because I can't find an example matching the video. > > > > > > > > > > > > Does anyone have a DMA example as he shows, or something similar. I've been using Xillybus thus far, which is great but isn't useful for high-speed transfers. > > > > > > > > > > > > Advance thanks, > > > > > > Karol. > > > > > > Hi, > > > > Never heard of Xillybus before, so I was curious to take a look at it. > > > > Why is it not useful for high-speed transfers? Page 17 of this manual discusses high speed IO. I only skim read it, but it seems to discuss the relevant technique, mapping user space RAM as a DMA buffer. > > > > http://xillybus.com/downloads/doc/xillybus_host_programming_guide_linux.pdf > > > > RupertArticle: 156389
Hi everyone, this is not really a question, but more some food for thoughts on how to optimize an fpga development flow leveraging the benefit of a vcs. I've been using svn since sometime now and I cannot imagine a world without a vcs under your belt when dealing with complex systems in a collaborative environment. In the past I've always followed two simple rules: 1. never break the trunk 2. commit often The reasons behind these two rules are quite simple and I stick to them because from them it derives a set of additional rules which allow you to respect the one above. The first rule is there because without it anyone new in the team cannot simply checkout a copy and rely on it. This implies that commits to the trunk are performed when a feature or a bugfix is completed and does not break compatibility with the rest of the system. Allowing a newcomer to easily get into the flow alleviates hours of training, but even experienced designers do need to rely on a stable version to perform their regression testing and/or add features to it. The second rule is needed because the very purpose of a vcs is to track changes as regularly as possible so that you (or somebody else) can roll back and forth and use what is most appropriate at any given time. Apparently the two rules are in contraddiction since the first advocates few commits (only the good ones) and the second lots of commits (even broken ones). To benefit from both of the two worlds 'branching' come to rescue. When branching the trunk we set up our working environment in a clean way and we can mess up with it as long as we want, until the feature/bugfix is complete. Only at that point we can merge it back into the trunk so that the trunk gets all the goodies we worked on. Working on a branch leaves (no pun intended) the trunk safe from exploration efforts and allows everyone to rely upon it. After all, an healthy trunk means an healthy tree. The pitfall here is that too often people branch and then never sync with the evolving trunk, so when it is time to merge it is a hell! Syncing regularly with the trunk allows to keep the branch on track without the risk to fight when it is time to close the branch and move on. I have deliberately left out of the flow the concept of tagging because that is not adding too much to this conversation and might be treated separately (maybe another thread ;-)). If you find this flow somehow lacking important features and/or missing completely essential points which are relevant to fpga development flow I'd appreciate if you could share your thoughts. Al -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 156390
In article <bpioa2F3io8U1@mid.individual.net>, alb <al.basili@gmail.com> wrote: > >this is not really a question, but more some food for thoughts on how to >optimize an fpga development flow leveraging the benefit of a vcs. > >I've been using svn since sometime now and I cannot imagine a world >without a vcs under your belt when dealing with complex systems in a >collaborative environment. > >In the past I've always followed two simple rules: > 1. never break the trunk > 2. commit often I'll add my 2 cents. Rule 1 is not as important in my experience. Having a regular regression (nightly, weekly, whatever), that runs on a clean checkout of the trunk is more important. Then you can easily identify what broke the trunk. The version control tools allow's everyone to continue working (by unmerging the offending commit). Rules 2 is spot on. Check in early, check in often. Working on branches is great, but as you indicated, merging sucks. The tools (SVN at least) allow easy branching, but are shitty when it comes to merges. If you've got a version control tool that allows for easy merging back to the trunk, then you've got the best of all. Atria (clearcase) really did this well, but was hell for admin, and performance sucked. I've no experience with the more modern distributed vcs (git, mercurial). Someone else hopefully will chime in here on how well they handle branches and merges... --MarkArticle: 156391
On 27/03/14 13:44, alb wrote:
> In the past I've always followed two simple rules:
> 1. never break the trunk
> 2. commit often
So, what do you put on the trunk and what's on the branches?
One strategy which works for some types of system and
some ways of team working is:
- to have the trunk for development
- whenever you reach a milestone of some sort,
create a branch containing the milestone
- whenever the regression tests have passed,
check in to the trunk (hopefully frequently)
- if it is necessary to save when regression
tests have not been passed, checkin to a branch
Thus
- the head of the trunk always contains the latest
working system.
- significant historical waypoints can be found on
a branch
Article: 156392On Friday, November 8, 2013 5:25:23 AM UTC-6, shrinivas gotur wrote: > hi guys, > > i was wondering whether can i have built in adc in fpga with good (say 12 or 14 bit) resolution and 0-5v input range will be available in market. please revert back soon if u know any.i am waiting You might find these of interest. http://davidkessner.wordpress.com/?s=fpgaArticle: 156393
Still gives out error if you have clock for other signals.. in other modules.. "Pack:1107 - Unable to combine the following symbols into a single IOB" I tried to set the "clock buffers" to just 1 so that It can contain the 1st clock in Project and It worked for Me!Article: 156394
I've managed to manually install Diamond ( latest 3.1 64-bit) on my Gentoo.
Now everything seems to be working, except programming the chip on board.
I am playing with their MachXO2 breakout board and such boards have FTDI-2232 chip for programming.
If doesn't matter if I start programming tool within Diamond or manually, it behaves the same.
It detects the FTDI chip, when I plug USB cable in the board and then start cable detect:
"Board with FTDI USB Host Chip detected.
INFO - Multiple cables detected!"
But if I try to scan chips in JTAG chain, i get:
"ERROR - Scan Failed - Creating Blank Programmer Project
The other process currently running. Cannot continue."
And programming attempt gets me:
"The other process currently running. Cannot continue."
So program can detect that the FTDI chip on breakout board is accessible, it just can't do anything with it.
I tried everything. I replaced the HW, cable, used different USB port, changed the FTDI VCP access library for newer one etc etc.
Nothing works. I don't think Diamond is that sensitive to library version since it packs all tricky libraries by itself.
Only thing I haven't checked yet is how the dynamic loader finds and loads them. It might be that some system libs are used instead of bundled ones.
Other thing that comes to mind is that maybe something within kernel changed wrt to files and maps in /sys directory ( sysfs).
After that, I'm out of options.
I am usiong a workaround atm - standalone programmer util on separate WinXP machine and I am about to try if I can do the same with 32-bit Linux version ( after failing with 64-bit one).
My system is:
AMD Phenom II x4 955BE stock
8 GiB RAM
Radeon 6850
all open source drivers AFAIR
Gentoo 64-bit with systemd+udev
xfce desktop
kernel gentoo-sources-3.13.7, without usb-serial and ftdi module driver
( if present they hog the ftdi chip and make two extra ttyS devices, while programmer expects to be able to access the chip directly)
And I had to add manually extra rule in udev so that at usb plugin udev would create device with right ownership and access rights so that programmer util could access it:
SUBSYSTEM=="usb" , ACTION=="add" , ATTR{idVendor}=="0403" , MODE="666" , OWNER="brane2" , GROUP="users"
So, if anyone has an idea, it is welcome.
Article: 156395Hi Mark, In comp.arch.fpga Mark Curry <gtwrek@sonic.net> wrote: [] >>In the past I've always followed two simple rules: >> 1. never break the trunk >> 2. commit often > > I'll add my 2 cents. Rule 1 is not as important in my experience. > Having a regular regression (nightly, weekly, whatever), that runs > on a clean checkout of the trunk is more important. Then you > can easily identify what broke the trunk. The version control > tools allow's everyone to continue working (by unmerging the > offending commit). and this is where I wanted to go in the first place, but there's no regression running regularly. Indeed the whole verification process is a bit of a mess, but that's another story! [1] In the event you *do not* have a regular regression you may now understand why rule 1 is in place. Without it, any commit may break the trunk silently until the next guy performs a sim and nothing works anymore. Without a regression in place every commit can break the trunk and it will take time before the issue comes out. Being able to branch and commit without fearing to break anything allows much more freedom to the developer to trace her/his changes. > Rules 2 is spot on. Check in early, check in often. this one is vital. You want to keep track of what you are doing, but you need to preserve the team sanity as well, so it would be too risky to allow everyone to commit early and often on a trunk. > Working on branches is great, but as you indicated, merging > sucks. The tools (SVN at least) allow easy branching, > but are shitty when it comes to merges. This happens because people branch and do not sync with the trunk regularly. I'm quite interested in understanding the technical reasons behind the merging issue in svn, sure is that without this possibility there's no way out of using only the trunk. > If you've got a version control tool that allows for > easy merging back to the trunk, then you've got the best > of all. The reason for this post is because I'm trying to raise arguments to convince people in the team to use svn and to profit from it. Proposing yet another tool to somebody who doesn't even see why we need a vcs is pointless and will only undermine the whole effort. > I've no experience with the more modern distributed vcs (git, mercurial). > Someone else hopefully will chime in here on how well they > handle branches and merges... I'm tempted about moving on to git, but I guess that it would be already a big success if the team accepts a fair usage of svn. On my own, I'll probably experiment with git-svn which seems to be a valuable tool to profit of git performances in an svn environment. Al [1] I'll soon post something about regression testing...and yes, that's a menace!Article: 156396
alb wrote: >> Working on branches is great, but as you indicated, merging >> sucks. The tools (SVN at least) allow easy branching, >> but are shitty when it comes to merges. > > This happens because people branch and do not sync with the trunk > regularly. I'm quite interested in understanding the technical reasons > behind the merging issue in svn, sure is that without this possibility > there's no way out of using only the trunk. In my experience merging in SVN works fine if every file is touched only by a single person. It only breaks in this situation: - Alice and Bob check out the latest trunk or create local branchges for themselves - they start making their changes - Bob is done and commits a change to file XYZ or merges his changed branch to the trunk. - Alice also works on her stuff, but also on file XYZ, but on the version that she originally checked out, not the one Bob has changed in the meantime. - Now Alice wants to merge her changes. Amongst others, her merge includes a changed version of file XYZ. But her version does not have the changes Bob made earlier. So now the SVN client sees that that file's revision in her branch that this new file is based on is older than the one in the trunk. Committing her file would probably mean reversing Bob's changes to XYZ, which could be intentional or a mistake. There's no way for the client to know for sure, so it just quits and complains and forces the user to manually decide which changes to apply. If this happens for a single file in a merge, the entire merge doesn't work, because half a merge would probably break everything. As long as every file is edited exclusively by one person, there should be no problem (at least I haven't had any). In past projects, this was mostly a problem with top-level files. Everyone is responsible for a module they work on exclusively, but if they add or change ports of that module, that has to be accounted for up through the hierarchy. So instead of changing the top-level-file, they should inform the person responsible for that file that the ports need to be changed. This is additional overhead but better than breaking merges completely; it never was a big problem for us, but I see it can be problematic in bigger projects with more people. I guess (don't know since I haven't looked into it) git and mercurial have some sort of mechanism to lock files or portions of files or track every detail you change, so during a merge the client can do step-by-step modifications of shared files, which maybe can resolve more uncertainties. Have fun, SeanArticle: 156397
Thanks for comments. Yes, it does seem like there's no good solution for this (when no training = pattern is available). Good ideas from Gabor and Lasse about deserialising the frame clock. Howeve= r, in my case, the data and the frame clock would come from different ports= on the ISERDESE2 (DDLY and D respectively) since the data comes from a pad= through an IDELAY and the frame clock comes from an MMCM. I don't know if = I can then fully trust the deserialised data to be in phase. I decided to drop the ISERDES and do my deserialiser in logic instead. A pi= ty I can't use the silicon resources though; a deterministic behaviour of t= he primitive, and it being documented, would have been enough.Article: 156398
On 20/03/14 08:41, Carl wrote: > I'm having some problems to understand the exact behavior of the ISERDESE2 primitive. What I need to understand is exactly how the unit will distribute the serial input to the bits in the output (paralell) words, or in other words, how ISERDESE aligns the frames on the incoming serial data stream in order to deliver the paralell words. > > In my case, I have no training pattern and hance can't find the right alignment with bitslip operations. I may be missing something, but if there is no training pattern then surely all alignments are equally valid. If not, then you need to specify how you know when the alignment is correct. Then take the ISERDES output, apply the specified algorithm, and (if necessary) shift the ISERDES output appropriately.Article: 156399
On Friday, March 28, 2014 2:32:03 PM UTC-4, Tom Gardner wrote: > I may be missing something, but if there is no training pattern then sure= ly all=20 > alignments are equally valid. If not, then you need to specify how you kn= ow=20 > when the alignment is correct. Then take the ISERDES output, apply the=20 > specified algorithm, and (if necessary) shift the ISERDES output appropri= ately. What you're missing is when the pattern is simply specified and therefore a= 'given'. An example, as Gabor mentioned, is Camera Link which specifies u= se of specific parts that are recommended for use for that interface. Thos= e parts sync it up so that the incoming low speed clock edges occurs on par= ticular high speed clock cycle. No training pattern is needed. With the FPGA SERDES primitives, no such alignment occurs automatically. F= urthermore, multriple SERDES primitives are not guaranteed to be aligned wi= th each other so each needs to be bit-slipped independently. When you try to implement a Camera Link interface (or any SERDES interface = that normally uses those same TI interface parts) using an FPGA, you will w= ant to either have control of both ends (so you can insert a training patte= rn) or come up with creative work arounds (like Gabor seems to have found). Kevin Jennings
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