Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi, I need this because of the stupid bureoacracy of my workplace. People in Turkey or USA are wanted. Thanks in advance, --enesArticle: 154801
>Hello, > >I'm looking for some kind person who could test my SD card controller. >Board with SD card slot with 4 data pins connected is needed. >I'm asking for it because I've designed my own board and I can trust it too >much ;) So I'd like to check if I have now hardware or VHDL problem. > >Best regards, >Pavel > >--------------------------------------- >Posted through http://www.FPGARelated.com > hi, I have a custom designed board with Xilinx xc95288 and a Micro SD memory slot(4bits), I am working on this topic (both 1 bit and 4 bit), I have not progressed in 4 bit so much so i 'm willing to test your hdl to learn more if you don't mind. Regards, Neda Baheri --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154802
In the 32-bit environment in Linux, the situation is even worse, as the attempt to use "In System Sources and Probes Editor" leads to segmentation fault:
*** Fatal Error: Segment Violation at 0x1c7
Module: quartus
Stack Trace:
0x44148: BNLQ_DATA_TABLE_VIEW::update_table_column(unsigned int) + 0x208 (sld_bnlq)
0x444fd: BNLQ_NODE_WIDGET::update_table_view(unsigned int) + 0x39 (sld_bnlq)
0x4579b: BNLQ_DATA_WIDGET::update_node_view(unsigned int) + 0xbb (sld_bnlq)
0x4588e: BNLQ_WIDGET::on_update(unsigned int) + 0xda (sld_bnlq)
0x4769f: BNLQ_LAYOUT_WIDGET::update_all_widgets(QWidget*, unsigned int) + 0x41 (sld_bnlq)
0x4e236: BNLQ_DATA_TABLE_VIEW::draw_timebar() + 0x104 (sld_bnlq)
0x52252: BNLQ_DATA_TABLE_VIEW_HEADER::mouseMoveEvent(QMouseEvent*) + 0x22a (sld_bnlq)
0x1aeb11: QWidget::event(QEvent*) + 0x611 (QtGui.so.4)
0x5b70f3: QFrame::event(QEvent*) + 0x33 (QtGui.so.4)
0x656392: QAbstractScrollArea::viewportEvent(QEvent*) + 0x32 (QtGui.so.4)
0x710265: QAbstractItemView::viewportEvent(QEvent*) + 0x525 (QtGui.so.4)
0x1798c1: QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) + 0x91 (QtCore.so.4)
0x1489a3: QApplicationPrivate::notify_helper(QObject*, QEvent*) + 0x93 (QtGui.so.4)
0x151104: QApplication::notify(QObject*, QEvent*) + 0x18f4 (QtGui.so.4)
0x17947b: QCoreApplication::notifyInternal(QObject*, QEvent*) + 0x7b (QtCore.so.4)
0x14b9a2: QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) + 0xf2 (QtGui.so.4)
0x1dafe6: QApplication::x11ProcessEvent(_XEvent*) + 0x1966 (QtGui.so.4)
0x17850d: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 0x4d (QtCore.so.4)
0x17879a: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 0xaa (QtCore.so.4)
0x17a811: QCoreApplication::exec() + 0xb1 (QtCore.so.4)
0x148317: QApplication::exec() + 0x27 (QtGui.so.4)
0x633f: __gxx_personality_v0 + 0x373 (quartus)
0x23208: msg_main_thread(void*) + 0x18 (ccl_msg)
0x5e5e: thr_final_wrapper + 0xe (ccl_thr)
0x23f1b: msg_thread_wrapper(void* (*)(void*), void*) + 0x6c (ccl_msg)
0x1591d: mem_thread_wrapper(void* (*)(void*), void*) + 0xdd (quartus)
0xffd8: err_thread_wrapper(void* (*)(void*), void*) + 0x2a (ccl_err)
0x62ba: thr_thread_wrapper + 0x2f (ccl_thr)
0x367c7: msg_exe_main(int, char const**, int (*)(int, char const**)) + 0xb7 (ccl_msg)
0x6411: __gxx_personality_v0 + 0x445 (quartus)
0x16e46: __libc_start_main + 0xe6 (c.so.6)
0x61f1: __gxx_personality_v0 + 0x225 (quartus)
End-trace
Quartus II 32-bit Version 12.1 Build 177 11/07/2012 SJ Web Edition
Article: 154803>>Hello, >> >>I'm looking for some kind person who could test my SD card controller. >>Board with SD card slot with 4 data pins connected is needed. >>I'm asking for it because I've designed my own board and I can trust it >too >>much ;) So I'd like to check if I have now hardware or VHDL problem. >> >>Best regards, >>Pavel >> >>--------------------------------------- >>Posted through http://www.FPGARelated.com >> > >hi, >I have a custom designed board with Xilinx xc95288 and a Micro SD memory >slot(4bits), I am working on this topic (both 1 bit and 4 bit), I have not >progressed in 4 bit so much so i 'm willing to test your hdl to learn more >if you don't mind. >Regards, >Neda Baheri > > >--------------------------------------- >Posted through http://www.FPGARelated.com > Hi Neda, I'm not sure if you got my message. If not, please write to me: pavelmlasek(at)gmail.com --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154804
On Tuesday, January 8, 2013 6:15:30 AM UTC-2, David Brown wrote: > On 08/01/13 03:06, Martin Schoeberl wrote:=20 > > MyHDL > > Chisel > > Lava > > Gezel > > JHDL > > Confluence > > HDCamel >=20 > Be careful that both Confluence and HDCamel are "dead" languages - the > single developer has moved on. I am not sure if this is also the case of IDaSS, which is written in Visual= Works Smalltalk and can generate VHDL and Verilog: http://averschu.home.xs4all.nl/idass/ I am planning to do something very similar. I don't like to have to write t= ext for things I understand more easily visually, like schematics and state= machines. I know that graphical representations aren't very dense compared= to text, but that just means we need better zooming and scrolling. -- JecelArticle: 154805
Hi all, A counter runs on system clock, counting from 0~95 in steps of 1. every 3 counts, registers for two signals are updated (data signal and write signal to ram). I first assumed both data and write target registers are multicycle but now have doubts since that implies that fitter may delay data signal differently from write signal though each is multicycle leading to wrong data being written into ram. Any thoughts please? Thanks Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154806
On Sunday, January 13, 2013 4:58:07 PM UTC-6, Jecel wrote: > On Tuesday, January 8, 2013 6:15:30 AM UTC-2, David Brown wrote: > On 08/= 01/13 03:06, Martin Schoeberl wrote: > > MyHDL > > Chisel > > Lava > > Geze= l > > JHDL > > Confluence > > HDCamel > > Be careful that both Confluence a= nd HDCamel are "dead" languages - the > single developer has moved on. I am= not sure if this is also the case of IDaSS, which is written in VisualWork= s Smalltalk and can generate VHDL and Verilog: http://averschu.home.xs4all.= nl/idass/ I am planning to do something very similar. I don't like to have = to write text for things I understand more easily visually, like schematics= and state machines. I know that graphical representations aren't very dens= e compared to text, but that just means we need better zooming and scrollin= g. -- Jecel I remember way too many years ago when I was faced with transitioning from = schematic entry to HDL based design entry for FPGAs. I ignorantly quipped t= o my boss; "Software is moving forward from writing code to drawing picture= s, why are we hell-bent for leather, moving in the opposite direction?!" Ye= ars later, he handed me a copy of a page from one of his notebooks on which= he had written it down, much to my chagrin. The answer lies in the decades of developement of the all design, implement= ation, analysis, review, test and revision management technology/practices = that have been developed to support code-based design entry for SW (though = SW considers coding as implementation, not design). We (HW) have been able = to leverage these SW technology/practices to immense benefit with regards t= o productivity, reliability and maintainability in FPGA and ASIC developmen= t.=20 Back to the subject at hand: How do graphical design entry methods leverage= these same (or equivalently robust) technologies and practices? For instan= ce, can a revision management system intelligently assist the user in mergi= ng multiple changes to a module, if that module was entered (and is maintai= ned) in graphical form? Can it intelligently (and thoroughly) compare two r= evisions of the design to see what changed, ignoring cosmetic changes? Can = it compare two modified revisions to their common ancester? These three exa= mples apply to only one of the several activities/technologies employed in = the development and mainenance of a product. AndyArticle: 154807
reposting sorry Hi all, A counter runs on system clock, counting from 0~95 in steps of 1. every 3 counts, registers for two signals are updated (data signal andwrite signal to ram). I first assumed both data and write target registers are multicycle but now have doubts since that implies that fitter may delay data signaldifferently from write signal though each is multicycle leading to wrongdata being written into ram. Any thoughts please? Thanks Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154808
On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote: > Hi all, A counter runs on system clock, counting from 0~95 in steps of 1.= every 3 counts, registers for two signals are updated (data signal and wri= te signal to ram). I first assumed both data and write target registers are= multicycle but now have doubts since that implies that fitter may delay da= ta signal differently from write signal though each is multicycle leading t= o wrong data being written into ram. Any thoughts please? Thanks Kaz ------= --------------------------------- Posted through http://www.FPGARelated.com First, registers are not multi-cylce paths. Paths are multicycle.=20 We cannot tell from your description whether you intend the paths into the = registers might be MC, or whether the path from the registers to the RAM mi= ght be MC.=20 Depending on how the RAM is enabled, the path from the registers to the RAM= might be multi-cycle.=20 It is impossible to know about the paths into the registers. Do ALL the sig= nals that drive ANY combinatorial logic that drives the registers (apart fr= om the implied clock enable) also only change on the same clock edge, every= 3rd clock? Finally, multi-cycle (and false) path constraints are the most difficult to= verify that you specified them correctly, and did not unintentionally rela= x the timing constraint on a specific path that is actually NOT MC/F. Verif= ying this takes either very expensive analysis tools, or carefully construc= ted, extensive simulations (with full timing) at the gate level. STA just a= ssumes you specified the constraint correctly.=20 AndyArticle: 154809
>On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote: >> Hi all, A counter runs on system clock, counting from 0~95 in steps of 1.= > every 3 counts, registers for two signals are updated (data signal and wri= >te signal to ram). I first assumed both data and write target registers are= > multicycle but now have doubts since that implies that fitter may delay da= >ta signal differently from write signal though each is multicycle leading t= >o wrong data being written into ram. Any thoughts please? Thanks Kaz ------= >--------------------------------- Posted through http://www.FPGARelated.com > >First, registers are not multi-cylce paths. Paths are multicycle.=20 > >We cannot tell from your description whether you intend the paths into the = >registers might be MC, or whether the path from the registers to the RAM mi= >ght be MC.=20 > >Depending on how the RAM is enabled, the path from the registers to the RAM= > might be multi-cycle.=20 > >It is impossible to know about the paths into the registers. Do ALL the sig= >nals that drive ANY combinatorial logic that drives the registers (apart fr= >om the implied clock enable) also only change on the same clock edge, every= > 3rd clock? > >Finally, multi-cycle (and false) path constraints are the most difficult to= > verify that you specified them correctly, and did not unintentionally rela= >x the timing constraint on a specific path that is actually NOT MC/F. Verif= >ying this takes either very expensive analysis tools, or carefully construc= >ted, extensive simulations (with full timing) at the gate level. STA just a= >ssumes you specified the constraint correctly.=20 > >Andy > Thanks Andy The count value itself is used as enable(rather than using explicit clkenable) My intention was that the path to above two registers is to be multicycled and I didn't include the paths to ram (though they might be as well). There are no other comb signals entering the scene. The data itself come from its registers that change every 3 clocks. The write is meant to be one clock pulse and is assigned from a wire set to '1' always. My concern is that the write signal(one high pulse every three clocks) may misalign with its data at ram leading to one extra wrong data or duplicate. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154810
On Monday, January 14, 2013 10:19:09 AM UTC-6, kaz wrote: > >On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote: >> Hi all, A co= unter runs on system clock, counting from 0~95 in steps of 1.=3D > every 3 = counts, registers for two signals are updated (data signal and wri=3D >te s= ignal to ram). I first assumed both data and write target registers are=3D = > multicycle but now have doubts since that implies that fitter may delay d= a=3D >ta signal differently from write signal though each is multicycle lea= ding t=3D >o wrong data being written into ram. Any thoughts please? Thanks= Kaz ------=3D >--------------------------------- Posted through http://www= .FPGARelated.com > >First, registers are not multi-cylce paths. Paths are m= ulticycle.=3D20 > >We cannot tell from your description whether you intend = the paths into the =3D >registers might be MC, or whether the path from the= registers to the RAM mi=3D >ght be MC.=3D20 > >Depending on how the RAM is= enabled, the path from the registers to the RAM=3D > might be multi-cycle.= =3D20 > >It is impossible to know about the paths into the registers. Do AL= L the sig=3D >nals that drive ANY combinatorial logic that drives the regis= ters (apart fr=3D >om the implied clock enable) also only change on the sam= e clock edge, every=3D > 3rd clock? > >Finally, multi-cycle (and false) pat= h constraints are the most difficult to=3D > verify that you specified them= correctly, and did not unintentionally rela=3D >x the timing constraint on= a specific path that is actually NOT MC/F. Verif=3D >ying this takes eithe= r very expensive analysis tools, or carefully construc=3D >ted, extensive s= imulations (with full timing) at the gate level. STA just a=3D >ssumes you = specified the constraint correctly.=3D20 > >Andy > Thanks Andy The count va= lue itself is used as enable(rather than using explicit clkenable) My inten= tion was that the path to above two registers is to be multicycled and I di= dn't include the paths to ram (though they might be as well). There are no = other comb signals entering the scene. The data itself come from its regist= ers that change every 3 clocks. The write is meant to be one clock pulse an= d is assigned from a wire set to '1' always. My concern is that the write s= ignal(one high pulse every three clocks) may misalign with its data at ram = leading to one extra wrong data or duplicate. Kaz -------------------------= -------------- Posted through http://www.FPGARelated.com OK, first, the functionality (whether clock cycles and data align properly = is not affected/dictated by a multi-cycle path constraint. The constraint o= nly relaxes the normal one-period STA-allowable propagation delay from any = register to any other register on the same clock signal.=20 Whether the clock cycles and data align or not is a function of the RTL, an= d should be observable in RTL simulation, and certainly in full-timing gate= level simulations. The gate level sims will also, if the correct condition= s are simulated, show you whether the RTL plus the final timing and delays = will still perform correctly.=20 From the sounds of it, if (and only if) the data to the registers is provid= ed by registers that only update themselves on the SAME clock cycle. It is = not enough to say that they both are enabled (only) every three clocks. The= y must be enabled (only) at the same time every three clocks. Then you can = probably put a multi-cyle path constraint of 3 clock cycles on the data pat= h between the registers. My rule of thumb is to NEVER add a multi-cycle path constraint unless the s= ynthesis and/or P&R tool is having problems making the timing, and there ar= e no other reasonable alternatives to resolve the problem (pipelining, etc)= . The reason is, as I said earlier, these constraints are very hard to veri= fy that they are accurately specified.=20 I used to go ahead and put multi-cycle path constraints in as soon as I was= aware of them (e.g. in RTL coding/simulation, before I even tried to synth= esize or P&R), so that the P&R tool would not work so hard to meet timing I= did not need. Then I got bit a time or two with bad assumptions about the = path and data (or changed the logic, and did not update the constraints!), = and learned (the hard way) why that was not a good idea.=20 There could be times when not having a MCP constraint could cause the place= r to distort the register placement such that other, single-cycle paths can= not be routed and meet timing. I'll run off that bridge when I get there...= It hasn't happened yet. Hope this helps, AndyArticle: 154811
On Monday, January 14, 2013 1:41:02 PM UTC-2, Andy wrote: > I remember way too many years ago when I was faced with transitioning fro= m > schematic entry to HDL based design entry for FPGAs. I ignorantly quipped > to my boss; "Software is moving forward from writing code to drawing pict= ures, > why are we hell-bent for leather, moving in the opposite direction?!" Yea= rs > later, he handed me a copy of a page from one of his notebooks on which h= e > had written it down, much to my chagrin. Schematics which could be unfolded on top of large desks were one thing, bu= t schematics broken up into A4/letter sized pages with one block per page a= nd labeled signals going to/from other pages are just very awkward netlists= . So I see it as a two step process - we first made drawings really bad (ha= ve you ever seen a good visual programming language?) and then we replaced = the result with text. =20 > The answer lies in the decades of developement of the all design, > implementation, analysis, review, test and revision management > technology/practices that have been developed to support code-based desig= n > entry for SW (though SW considers coding as implementation, not design). = We > (HW) have been able to leverage these SW technology/practices to immense > benefit with regards to productivity, reliability and maintainability in = FPGA > and ASIC development.=20 As a Smalltalker, I have always considered these software tools an unfortun= ate joke. But they are better than nothing and I have created my own system= s (just because CVS, GIT and friends didn't exist when I did this) for the = C side. > Back to the subject at hand: How do graphical design entry methods levera= ge > these same (or equivalently robust) technologies and practices? For insta= nce, > can a revision management system intelligently assist the user in merging > multiple changes to a module, if that module was entered (and is maintain= ed) > in graphical form? Can it intelligently (and thoroughly) compare two revi= sions > of the design to see what changed, ignoring cosmetic changes? Can it comp= are > two modified revisions to their common ancester? These three examples app= ly to > only one of the several activities/technologies employed in the developme= nt > and mainenance of a product. I don't think diff does such a good job of ignoring cosmetic differences in= two text files. But you are correct that graphics add a level of complicat= ions. Changing a pin in a library component which has both a schematic symb= ol and a PCB layout, for example, is something a lot of tools don't get qui= te right. So I think you can get further with a bad text implementation than with a b= ad graphical tool, but if done well then the graphical one will be more usa= ble. -- JecelArticle: 154812
I creating an FPGA implementation of a old DEC PDP-10 (KS-10, specifically) Mainframe Computer. Why? Because I always wanted one... The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU. At this stage, most of the instruction set diagnostics simulate correctly. When I synthesize this design using Xilinx ISE I get warnings about combinatorial loops involving the ALU - and an associated "Minimum period: 656.595ns (Maximum Frequency: 1.523MHz)" message... My understanding is that if combination loops really existed then the simulation wouldn't stabilize. I can't really add pipelining or registers to the design without affecting the microcode - and I don't want to do that. Most of the information that I've read about "false paths" assume two clocked processes not a combinatorial loop. Anyway. I'm not sure how to resolve this. I can mark the path as a false path but I think that it will ignore /all/ the timing (even the desired timing) through that path. What should I do? Rob.Article: 154813
hi i want to write a vhdl code for booth modified radix4 algorithm using wallace tree(3:2) and need help in this.. please helpArticle: 154814
Thanks Andy, it all makes sense. I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle of input register itself) to improve timing which we are struggling with. The design was showing malfunction pointing to that multicycle area. I removed the multicycle (only this change made to build) and it is now outputting correct expected spectrum. So I have to assume it was wrong multicycle but my own paper analysis indicated it could be multicycle. I believe the issue of multicycle must be automated by tools as part of timing analysis as it is indeed very hard to get right in many cases. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154815
On Tuesday, January 15, 2013 6:52:23 AM UTC-6, kaz wrote: > Thanks Andy, it all makes sense. I set to multicycle of 2 (rather thn 3 f= or reasons to do with clock cycle of input register itself) to improve timi= ng which we are struggling with. The design was showing malfunction pointin= g to that multicycle area. I removed the multicycle (only this change made = to build) and it is now outputting correct expected spectrum. So I have to = assume it was wrong multicycle but my own paper analysis indicated it could= be multicycle. I believe the issue of multicycle must be automated by tool= s as part of timing analysis as it is indeed very hard to get right in many= cases. Kaz --------------------------------------- Posted through http://w= ww.FPGARelated.com I believe you have hit upon the main reason I avoid MCP constraints. It is = too easy to overly broadly specify the paths that are covered by an MCP, wh= ich lead to issues that may be difficult to identify and debug. You were lu= cky that the effects showed up quickly.=20 STA is strictly a structural analysis of the results of placing and routing= the FPGA. It does not include any knowledge about the functionality of the= logic, other than what is a combinatorial primitive, and what is a sequent= ial primitive. Therefore, adding identification or verification of MCP cons= traints to this process would be very difficult (the necessary information = is not available in this process). There are SW tools that perform analysis or even generation of multi-cycle = and false path constraints from the RTL. Blue Pearl Software has one such t= ool. I do not know much at all about it. If such capability were to be inte= grated into the tool suite, it would likely be into the synthesis process, = not the timing analysis process.=20 AndyArticle: 154816
Hello, I asked some time ago for constraints learning materials. It is hard to learn only with reading, I think I should try it. Here comes the time when I think only that can help me. I have problem with sending data to SD memory. Data output and checksum values seem to be fine, but SD says that there is checksum error. It works with 50MHz. I suppose that there might be some delay between clock and data, maybe you could suggest something else? Could you help me with applying constraints to let the tools know that they should be more careful with that sensitive data output part of design? The only constraint, besides LOC for pinout, which I use is: NET "clock" TNM_NET = "tnm_clock"; TIMESPEC "TS_clock" = PERIOD "tnm_clock" 20 ns HIGH 50 %; But to be honest I don't see much difference with or without it. I just read that it is one of basic and "must be" constraint. Best regards, Pavel --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154817
jonesandy@comcast.net wrote:
> On Tuesday, January 15, 2013 6:52:23 AM UTC-6, kaz wrote:
>> Thanks Andy, it all makes sense. I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle of input register itself) to improve timing which we are struggling with. The design was showing malfunction pointing to that multicycle area. I removed the multicycle (only this change made to build) and it is now outputting correct expected spectrum. So I have to assume it was wrong multicycle but my own paper analysis indicated it could be multicycle. I believe the issue of multicycle must be automated by tools as part of timing analysis as it is indeed very hard to get right in many cases. Kaz --------------------------------------- Posted through http://www.FPGARelated.com
>
> I believe you have hit upon the main reason I avoid MCP constraints. It is too easy to overly broadly specify the paths that are covered by an MCP, which lead to issues that may be difficult to identify and debug. You were lucky that the effects showed up quickly.
>
> STA is strictly a structural analysis of the results of placing and routing the FPGA. It does not include any knowledge about the functionality of the logic, other than what is a combinatorial primitive, and what is a sequential primitive. Therefore, adding identification or verification of MCP constraints to this process would be very difficult (the necessary information is not available in this process).
>
> There are SW tools that perform analysis or even generation of multi-cycle and false path constraints from the RTL. Blue Pearl Software has one such tool. I do not know much at all about it. If such capability were to be integrated into the tool suite, it would likely be into the synthesis process, not the timing analysis process.
>
> Andy
Tools that automatically create multicycle constraints are not
inexpensive!
I generally only use milticycle constraints on registers that
are clearly coded to use a periodic clock enable. Even then,
using the clock enable itself as a selector for the timing
group can bite you if you have also used the clock enable as
a feedback to itself like:
if rising_edge(clock) then
clock_enable <= not clock_enable;
end if;
If you then use TNM_NET with clock_enable, you'll find that the
clock enable itself is included in this timing group. Obviously
the clock enable should not be considered as a multicycle path.
So you need to be careful how you define your clock enable if
you're using it to determine multicycle paths.
You can of course use the actual net names to define the timing
groups for multicycle paths, but then you can often get into
trouble by using wildcards that match nets you didn't expect.
-- Gabor
Article: 154818Rob Doyle wrote: > > I creating an FPGA implementation of a old DEC PDP-10 (KS-10, > specifically) Mainframe Computer. Why? Because I always wanted one... > > The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU. > At this stage, most of the instruction set diagnostics simulate correctly. > > When I synthesize this design using Xilinx ISE I get warnings about > combinatorial loops involving the ALU - and an associated "Minimum > period: 656.595ns (Maximum Frequency: 1.523MHz)" message... > > My understanding is that if combination loops really existed then the > simulation wouldn't stabilize. I can't really add pipelining or > registers to the design without affecting the microcode - and I don't > want to do that. > Combinatorial loops _with delay_ will simulate correctly. Otherwise you couldn't simulate a ring oscillator. > Most of the information that I've read about "false paths" assume two > clocked processes not a combinatorial loop. > > Anyway. I'm not sure how to resolve this. I can mark the path as a > false path but I think that it will ignore /all/ the timing (even the > desired timing) through that path. > Not necessarily true. False paths have a FROM and a TO specification, and would not affect other paths that don't start at the FROM or don't end at the TO timing group. This allows you for example to say that you don't care how long a control register bit takes to get through some logic, but you want the streaming data to get through in the standard PERIOD time. > What should I do? You could always run your machine at 1.5 MHz. After all, how fast was the PDP-10? Other than that, we'd probably need to analyze this path to give any useful advice. > > Rob.Article: 154819
pavel.m wrote: > Hello, > > I asked some time ago for constraints learning materials. It is hard to > learn only with reading, I think I should try it. > > Here comes the time when I think only that can help me. I have problem with > sending data to SD memory. Data output and checksum values seem to be fine, > but SD says that there is checksum error. It works with 50MHz. I suppose > that there might be some delay between clock and data, maybe you could > suggest something else? > Could you help me with applying constraints to let the tools know that they > should be more careful with that sensitive data output part of design? > > The only constraint, besides LOC for pinout, which I use is: > NET "clock" TNM_NET = "tnm_clock"; > TIMESPEC "TS_clock" = PERIOD "tnm_clock" 20 ns HIGH 50 %; > > But to be honest I don't see much difference with or without it. I just > read that it is one of basic and "must be" constraint. > > Best regards, > Pavel > > > --------------------------------------- > Posted through http://www.FPGARelated.com The PERIOD constraint is a good starting point, but it only covers internal paths from one flip-flop or other register (BRAM, DSP48...) to another inside the FPGA. Checksum errors could very likely indicate an issue with the interface timing, which includes clock to output of the FPGA, and setup/hold time at FPGA inputs. You need to check the specs on your external device to calculate the allowable setup and hold time at the FPGA. Then you need to add an OFFSET IN BEFORE constraint to ensure that these conditions are met by the design. For example if you determine that you have 3 ns setup and 2 ns hold time with respect to the rising edge of the "clock" net: OFFSET = IN 3 ns VALID 5 ns BEFORE "clock" RISING ; This says that the valid data window starts 3 ns before the rising edge of the clock input pin, and stays valid for 5 ns - that is until 2 ns after the rising edge of clock. You can also constrain the clock to output timing like: OFFSET = OUT 5 ns AFTER "clock" RISING; This sets a maximum delay from the clock input pin to an output pad. Note that there is no way to constrain a minimum delay, so if you are using source-synchronous logic, you need to be sure that output timing is met by design. Normally this means placing output flops in the IOB and using a DDR output register for the clock running on a different phase from the data to allow hold time if necessary. -- GaborArticle: 154820
On Jan 14, 11:25=A0pm, Jecel <je...@merlintec.com> wrote: > On Monday, January 14, 2013 1:41:02 PM UTC-2, Andy wrote: > > The answer lies in the decades of developement of the all design, > > implementation, analysis, review, test and revision management > > technology/practices that have been developed to support code-based des= ign > > entry for SW (though SW considers coding as implementation, not design)= . We > > (HW) have been able to leverage these SW technology/practices to immens= e > > benefit with regards to productivity, reliability and maintainability i= n FPGA > > and ASIC development. > > As a Smalltalker, I have always considered these software tools an unfort= unate joke. But they are better than nothing and I have created my own syst= ems (just because CVS, GIT and friends didn't exist when I did this) for th= e C side. > > > Back to the subject at hand: How do graphical design entry methods leve= rage > > these same (or equivalently robust) technologies and practices? For ins= tance, > > can a revision management system intelligently assist the user in mergi= ng > > multiple changes to a module, if that module was entered (and is mainta= ined) > > in graphical form? Can it intelligently (and thoroughly) compare two re= visions > > of the design to see what changed, ignoring cosmetic changes? Can it co= mpare > > two modified revisions to their common ancester? These three examples a= pply to > > only one of the several activities/technologies employed in the develop= ment > > and mainenance of a product. > > I don't think diff does such a good job of ignoring cosmetic differences = in two text files. But you are correct that graphics add a level of complic= ations. Changing a pin in a library component which has both a schematic sy= mbol and a PCB layout, for example, is something a lot of tools don't get q= uite right. Diff (in CVS) does a horrible job! Try something capable like BeyondCompare. Even the comparison capapilities in TortoiseSVN are better than CVS/diff (I have not tried tortoiseCVS, it may be very similar to tortoiseSVN). > > So I think you can get further with a bad text implementation than with a= bad graphical tool, but if done well then the graphical one will be more u= sable. > > -- Jecel Generally, if you work on a lot of small, one-man, one-off projects, these capabilities may not interest you or make you more productive. But when you work on large projects with several developers and a long product life-cycles, these capabilities rise to the top. Also, I think the relative preference of graphical/textual design entry has a lot to do with your design style. If you tend to be a very structural, concrete HW designer (e.g. if you think in terms of circuit elements that will do what you want), the schematic paradigm probably works great. If on the other hand, you prefer designing at higher levels of abstraction, and focus on the intended behavior of the design, along with throughput and latency, then a textual paradigm works better. Sure, there is still plenty of structure in even an abstract, behavioral (yet synthesizeable) design of any size/complexity, but abstracting interfaces using custom, aggregate data types (records, arrays, arrays of arrays, arrays of records, etc.) reduces the tediousness of the coding, and improves readability and maintainability. AndyArticle: 154821
On Jan 15, 2:33=A0pm, GaborSzakacs <ga...@szakacs.invalid> wrote: > > Tools that automatically create multicycle constraints are not > inexpensive! > > I generally only use milticycle constraints on registers that > are clearly coded to use a periodic clock enable. =A0Even then, > using the clock enable itself as a selector for the timing > group can bite you if you have also used the clock enable as > a feedback to itself like: > > =A0 =A0if rising_edge(clock) then > =A0 =A0 =A0 clock_enable <=3D not clock_enable; > =A0 =A0end if; > > If you then use TNM_NET with clock_enable, you'll find that the > clock enable itself is included in this timing group. =A0Obviously > the clock enable should not be considered as a multicycle path. > So you need to be careful how you define your clock enable if > you're using it to determine multicycle paths. > > You can of course use the actual net names to define the timing > groups for multicycle paths, but then you can often get into > trouble by using wildcards that match nets you didn't expect. > > -- Gabor Agreed on the cost of those tools... Tools like that have to be leveraged across larger design teams. Clock enable signals are almost NEVER multicycle themselves, regardless of how they were generated (feedback or not). They still have to propagate (on and off) from their source register to every enabled register in only one clock. And wildcards are just begging to include paths you did not intend to include. When done accurately, they work great. The problem is verifying they were done accurately. And just because a path is multi- cycle constrained, does not mean it WILL take multiple clocks to propagate in the final P&R results, making it impossible to know whether it could have been multi-cycle and still worked. You'll never know until some design/tool change suddenly lengthens the propagation to longer than one clock, and boom! It is relatively easy to add assert statements in the RTL such that you can detect if the signal ever changes more recently than your assumed MCP constraint, even in RTL simulation. The problem is making sure the constrained paths are the same ones checked by the the assertion! AndyArticle: 154822
On 1/15/2013 7:52 AM, kaz wrote: > Thanks Andy, it all makes sense. > > I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle > of > input register itself) to improve timing which we are struggling with. The > design was showing malfunction pointing to that multicycle area. > I removed the multicycle (only this change made to build) and it is now > outputting correct expected spectrum. > > So I have to assume it was wrong multicycle but my own paper analysis > indicated > it could be multicycle. > > I believe the issue of multicycle must be automated by tools as part of > timing > analysis as it is indeed very hard to get right in many cases. I find multicycle constraints to be a very simple issue. As was explained, it is the paths that are constrained, not the registers. So think in terms of the paths. You have multicycle paths ending at some registers. These paths need to be constrained with the correct time values. The register enables (or write enables in your case) are still single clock cycle paths. So you need to make sure the enables are constrained with the single clock period. If you apply the longer, multicycle constraint to the enable paths, you may well end up with misaligned enables and data because of excessive path delays. That is all there is to "multicycle" timing constraints. But of course the devil is in the details. I don't know what tools you are using and I'm not familiar with every tool family, so I likely couldn't give you detailed info on just how to apply timing constraints in your case. What was said about the tools not being too smart about verifying timing constraints is, in my opinion, a major shortcoming of the tools. We have powerful tools to verify our logic and our timing... but not the timing constraints which drive the timing analysis. Everything about engineering is verification. So I find it odd that you can't verify your timing constraints in any useful way. If you are concerned that your timing constraints are working correctly, you can run a post-route simulation which will include timing. This can help, but likely won't catch all potential issues. RickArticle: 154823
On 1/15/2013 12:54 AM, Rob Doyle wrote: > > I creating an FPGA implementation of a old DEC PDP-10 (KS-10, > specifically) Mainframe Computer. Why? Because I always wanted one... > > The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU. > At this stage, most of the instruction set diagnostics simulate correctly. > > When I synthesize this design using Xilinx ISE I get warnings about > combinatorial loops involving the ALU - and an associated "Minimum > period: 656.595ns (Maximum Frequency: 1.523MHz)" message... > > My understanding is that if combination loops really existed then the > simulation wouldn't stabilize. I can't really add pipelining or > registers to the design without affecting the microcode - and I don't > want to do that. > > Most of the information that I've read about "false paths" assume two > clocked processes not a combinatorial loop. > > Anyway. I'm not sure how to resolve this. I can mark the path as a > false path but I think that it will ignore /all/ the timing (even the > desired timing) through that path. > > What should I do? Do you know why the tool is complaining? Did you write the code describing the ALU? Off the top of my head, I can't think of why an ALU would have a combinatorial loop. It should have two input data busses, a number of control inputs, an output data bus and some output status signals. I don't recall the details of the 2901 bit slice and my data books are not handy. That's the problem with paper books, you can't just shove them on your hard drive... Does this part have an internal register file? Even so, that means the part would have a clock and not a combinatorial loop. Maybe this is because of some internal bus that is shared in a way that looks like a loop even though it would never be used that way? I may have to find my old AMD data book. That could be an archeological dig! RickArticle: 154824
On Tuesday, January 15, 2013 8:30:10 PM UTC-2, Andy wrote: > Diff (in CVS) does a horrible job! Try something capable like > BeyondCompare. Even the comparison capapilities in TortoiseSVN are > better than CVS/diff (I have not tried tortoiseCVS, it may be very > similar to tortoiseSVN). Thanks for the tip. I was talking about the diff tools normally found in Li= nux. But my point was that while it is an easier problem to solve for text = than for graphics, it isn't always well done for text and I hope I can get = good results for graphics. > Generally, if you work on a lot of small, one-man, one-off projects, > these capabilities may not interest you or make you more productive. > But when you work on large projects with several developers and a long > product life-cycles, these capabilities rise to the top. Agreed. > Also, I think the relative preference of graphical/textual design > entry has a lot to do with your design style. If you tend to be a very > structural, concrete HW designer (e.g. if you think in terms of > circuit elements that will do what you want), the schematic paradigm > probably works great. Though the sources that Sun released for its various processors were text-o= nly Verilog, they are essentially a netlist of very low level primitives th= at they defined themselves. I found this very hard to understand compared t= o a more behavioral and higher level description. It might have evolved fro= m a previous visual development method, as you said. > If on the other hand, you prefer designing at higher levels of > abstraction, and focus on the intended behavior of the design, along > with throughput and latency, then a textual paradigm works better. > Sure, there is still plenty of structure in even an abstract, > behavioral (yet synthesizeable) design of any size/complexity, but > abstracting interfaces using custom, aggregate data types (records, > arrays, arrays of arrays, arrays of records, etc.) reduces the > tediousness of the coding, and improves readability and > maintainability. While generators (parameterized IP in general, actually) are really awkward= to represent visually, I don't think any of the things you mentioned is a = problem that only text can solve. -- Jecel
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