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 Ashish, I am instantiating a MicroBlaze, in that case also do I need to see wether the PPC is coming out of RESET block. Can you please suggest me the ways to check the locking and configuration of DCM units, because this tool is kind of new to me. In the mean time I will be trying at my end also, but if you can give some directions, it will be of great help to me. Regards, Shant Chandrakar On Feb 2, 5:04 am, "Ashish" <ashish.shringarp...@gmail.com> wrote: > On Jan 31, 2:49 am, "Shant" <shantchandra...@gmail.com> wrote: > > > > > Hi All, > > > I am a Newbie and I am trying to load my C program on an FPGA using > > through EDK 8.1i without using BSB (since it does not support multiple > > processors). I am using Xilinx's ML310 development board for the same > > and. I am using Jtag cable for connection. After downloading my > > program on the FPGA and launching XMD I am getting the following > > messages: > > > Xilinx Microprocessor Debug (XMD) Engine > > Xilinx EDK 8.1.02 Build EDK_I.20.4 > > Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved. > > > XMD% > > Loading XMP File.. > > Processor(s) in System :: > > > Microblaze(1) : microblaze_0 > > Address Map for Processor microblaze_0 > > (0x00000000-0x00001fff) lmb_bram_if_cntlr_1 lmb_v10_0 > > (0x00000000-0x00001fff) lmb_bram_if_cntlr_0 lmb_v10_1 > > (0x80000000-0x800000ff) opb_uartlite_0 opb_v20_0 > > (0x80000100-0x800001ff) opb_mdm_0 opb_v20_0 > > > Connecting to cable (Parallel Port - LPT1). > > Checking cable driver. > > Driver windrvr6.sys version = 7.0.0.0. LPT base address = 0378h. > > ECP base address = 0778h. > > ECP hardware is detected. > > Cable connection established. > > Connecting to cable (Parallel Port - LPT1) in ECP mode. > > Checking cable driver. > > Driver xpc4drvr.sys version = 1.0.4.0. LPT base address = 0378h. > > Cable Type = 1, Revision = 3. > > Setting cable speed to 5 MHz. > > Cable connection established. > > > JTAG chain configuration > > -------------------------------------------------- > > Device ID Code IR Length Part Name > > 1 0a001093 8 System_ACE > > 2 0127e093 14 XC2VP30 > > Assuming, Device No: 2 contains the MicroBlaze system > > Connected to the JTAG MicroProcessor Debug Module (MDM) > > No of processors = 1 > > > UNKNOWN Processor Version (0) > > Verify if FPGA Bitstream was downloaded and DONE pin went High > > > During download process, LEDs for OPB ERR and PLB ERR becomes Red for > > a while and then becomes green again. Once the Download process > > finishes, the INIT LED goes Low and DONE LED goes Green. > > For Verifying the download, I also tried downloading my program > > through iMPACT and doing the verification afterwards, but then also I > > am getting the same message again. > > > Apart from this, the tutorial also asks for invoking the HyperTerminal > > before starting the download process, I also did the same using COM1 > > (after connecting the serial port cable ) with > > Baud rate of 9600, > > Data 8 bits, > > Parity None, > > Stop 1 and > > Flow Control None > > > And it mentions about the print statements getting displayed on the > > HyperTerminal. But I could not see anything on the HyperTerminal. > > > I am not in a position to understand why it is happening. So please > > suggest your expert comments on this problem of mine. > > > Thanks, > > Shant Chandrakar > > Hi, > > It might be that PPC is not coming out of RESET check your reset > block. > > Most of the time its reset problem. > > You can also check if your DCM's are locking correctly and they are > correctly configured. > > Check this and regenerate bit file and try again. > Enjoy.. > > AshishArticle: 115226
On Feb 3, 5:20 pm, "Mr B" <bharadwaj...@gmail.com> wrote: > On Feb 3, 1:17 am, "Peter Alfke" <a...@sbcglobal.net> wrote: > > > > > This is a very complicated subject, with many hundred man-years of > > development behind it. > > Tell us: > > Why do you want to know, or why do you need to know? > > Peter Alfke, Xilinx > > > On Feb 2, 10:02 pm, "2mao" <zhouh...@gmail.com> wrote: > > > > On 2=E6=9C=883=E6=97=A5, =E4=B8=8A=E5=8D=885=E6=97=B650=E5=88=86, bha= radwaj...@gmail.com wrote: > > > > > Hey All... > > > > > Is there a way to decode the interconnect/Routing algorithm used by > > > > Xilinx???? I see that the XDL file gives information on the routing > > > > details. However, the interconnect/Routing details are given as > > > > numbers. Also, > > > > It gives info on PIPs, but I really dunno how to decode it. Could > > > > somebody help me out..... > > > > > Thanx in advance! > > > > > Mr.B > > > > I want to know it too. > > I know It is way too complicated..... :-) I am working on partial > reconfiguration ryte now....my prof wanted me to dig deep dwn into > it......if I get to know abt the routing details, I may b able to work > on different benchmark ckts.... > > Thank you pete..... > > Mr.B Hey Pete... Could u plz tel me watz happening wid the XDL file.... Thanks in Advance Mr.BArticle: 115227
Well, it's polite enough, but look at that spelling... What did I spend 20 years in school for? Peter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Feb 3, 5:27=C2=A0pm, "Mr B" <bharadwaj...@gmail.com> wrote: > On Feb 3, 5:20 pm, "Mr B" <bharadwaj...@gmail.com> wrote: > > > > > On Feb 3, 1:17 am, "Peter Alfke" <a...@sbcglobal.net> wrote: > > > > This is a very complicated subject, with many hundred man-years of > > > development behind it. > > > Tell us: > > > Why do you want to know, or why do you need to know? > > > Peter Alfke, Xilinx > > > > On Feb 2, 10:02 pm, "2mao" <zhouh...@gmail.com> wrote: > > > > > On 2=E6=9C=883=E6=97=A5, =E4=B8=8A=E5=8D=885=E6=97=B650=E5=88=86, b= haradwaj...@gmail.com wrote: > > > > > > Hey All... > > > > > > Is there a way to decode the interconnect/Routing algorithm used = by > > > > > Xilinx???? =C2=A0I see that the XDL file gives information on the= routing > > > > > details. However, the interconnect/Routing details are given as > > > > > numbers. Also, > > > > > It gives info on PIPs, but I really dunno how to decode it. Could > > > > > somebody help me out..... > > > > > > Thanx in advance! > > > > > > Mr.B > > > > > I want to know it too. > > > I know It is way too complicated..... :-) I am working on partial > > reconfiguration ryte now....my prof wanted me to dig deep dwn into > > it......if I get to know abt the routing details, I may b able to work > > on different benchmark ckts.... > > > Thank you pete..... > > > Mr.B > > Hey Pete... > > Could u plz tel me watz happening wid the XDL file.... > > Thanks in Advance > > Mr.BArticle: 115228
On Feb 2, 7:12 am, "idp2" <ian.pei...@gmail.com> wrote: > I am constantly getting the following warnings when compiling in > Xilinx: > FF/Latch <thresh_0> (without init value) has a constant value of 0 in > block <calibrate> > > I do not understand why this happens since I set thresh to 0 on rst > signal. > Here's my code: > > //determine the threshold value > reg[7:0] thresh; > always @(posedge clk) > begin > if(~done & stepCnt==2 & cal_cnt==3 & sampCtr==511) > thresh <= mean8*ALPHA; > else if(rst) > thresh[7:0] <= 8'h00; > end > > Thanks, > Ian Hi Ian, Have you tried to code it as: reg[7:0] thresh = 8'h00; This would ensure that you are always have an init condition as talked about in the XST user guide. As much as possible try and avoid resets of any kind unless it is absolutely needed. As Gabor pointed out, the issue is that you are getting a latch. The reason XST says without an initial value is because then you will not need a latch, as it can default to a value in the condition where "else" should be. When coding a FF, ensure that you cover all conditions, or the synthesis tool will need to latch to the previous value. Do the same initialization for the DMA addr as well. This should fix the issue. If it does not, go ahead and open a case with Tech Support and let them know that the message was not clarifying the true cause of the issue. Thanks DuthArticle: 115229
Uwe Bonnes wrote: > Symon <symon_brewer@hotmail.com> wrote: >> "Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> wrote in message >> news:epo8vh$j20$1@lnx107.hrz.tu-darmstadt.de... >>> Thomas Reinemann <tom.reinemann@gmx.net> wrote: >>>> Hello, >>>> we want to use a Spartan-3A to collect signals of about 100 >>>> differential lines. This type offers the possibility for on-chip LVDS >>>> termination. Is there a limit how many pairs per bank can be >>>> terminated via the on-chip resistor? Where may I find further >>>> information? >>> Often LVDS on-chip Termination is a power hog on Xilinx chips. >>> Consider using a multi channel LVDS transceiver. like the SN65LVDM1677. It >>> eases layout and spares you a lot of pins. >>> >> Hi Uwe, >> Are you saying that LVDS uses more power than LVDS_DT from the Xilinx >> supplies? That surprises me. Could you point me in the direction of some >> documentation for this? Or maybe you're refering to the DCI modes? >> Thanks, Syms. > > I meant the problem with excessive power for LVDS with on-chip DCI > termination. Be careful also that you do not fry the Spartan 3A when you use DCI termination for 100 differential lines as all the power dissipated will be within the chip. The advantage of using external termination resistors or LVDS devices is that the power is not dissipated within the FPGA. BenArticle: 115230
Why speculate when it is all described in the appropriate user guide? The differential termination is internal, and consumes hardly any power, since it is truly differential, not the fake differential power hog implemented in DCI. And UG331 on page 338/339 clearly states that you can use either 3.3 or 2.5 V (but at 2.5 V the differential termination resistor is not as precise a value). Peter Alfke ========================== On Jan 30, 12:14 pm, Uwe Bonnes <b...@hertz.ikp.physik.tu- darmstadt.de> wrote: > Thomas Reinemann <tom.reinem...@gmx.net> wrote: > > Hello, > > we want to use a Spartan-3A to collect signals of about 100 > > differential lines. This type offers the possibility for on-chip LVDS > > termination. Is there a limit how many pairs per bank can be > > terminated via the on-chip resistor? Where may I find further > > information? > > Often LVDS on-chip Termination is a power hog on Xilinx chips. > Consider using a multi channel LVDS transceiver. like the SN65LVDM1677. It > eases layout and spares you a lot of pins. > > -- > Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 115231
Francesco wrote: > Hi, I'm just wondering how many people here are using ISE 9.1. > Could you post your experience here? Because of my 9.1i problem with synthesis, I'm back to 8.1i. Now the console window in the ISE GUI doesn't automatically scroll correctly. What should be happening is that new text appears on the bottom line of the console window, and the old text scrolls off the top of the window. Instead, the display is frozen in one place, and I have to constantly scroll down to see the new text. Is there a registry setting that controls this, because it doesn't seem to be a preference in 8.1i. --- Joe Samson Pixel VelocityArticle: 115232
Joseph Samson wrote: > Francesco wrote: >> Hi, I'm just wondering how many people here are using ISE 9.1. >> Could you post your experience here? > Because of my 9.1i problem with synthesis, I'm back to 8.1i. Now the > console window in the ISE GUI doesn't automatically scroll correctly. > What should be happening is that new text appears on the bottom line of > the console window, and the old text scrolls off the top of the window. > Instead, the display is frozen in one place, and I have to constantly > scroll down to see the new text. Is there a registry setting that > controls this, because it doesn't seem to be a preference in 8.1i. > > --- > Joe Samson > Pixel Velocity I remember on service pack of the software that had display problems. Changing from a display that forces you to the bottom of the log (so far) when you're trying to review information so far was a HUGE improvement. If you try the latest service pack for 8.1 or consider going to the latest 8.x service pack and release you will be MUCH better off all around, not just for the display issue.Article: 115233
Ben Popoola wrote: > Uwe Bonnes wrote: >> Symon <symon_brewer@hotmail.com> wrote: >>> "Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> wrote in message >>> news:epo8vh$j20$1@lnx107.hrz.tu-darmstadt.de... >>>> Thomas Reinemann <tom.reinemann@gmx.net> wrote: >>>>> Hello, >>>>> we want to use a Spartan-3A to collect signals of about 100 >>>>> differential lines. This type offers the possibility for on-chip LVDS >>>>> termination. Is there a limit how many pairs per bank can be >>>>> terminated via the on-chip resistor? Where may I find further >>>>> information? >>>> Often LVDS on-chip Termination is a power hog on Xilinx chips. >>>> Consider using a multi channel LVDS transceiver. like the >>>> SN65LVDM1677. It >>>> eases layout and spares you a lot of pins. >>>> >>> Hi Uwe, >>> Are you saying that LVDS uses more power than LVDS_DT from the Xilinx >>> supplies? That surprises me. Could you point me in the direction of >>> some documentation for this? Or maybe you're refering to the DCI modes? >>> Thanks, Syms. >> >> I meant the problem with excessive power for LVDS with on-chip DCI >> termination. > > Be careful also that you do not fry the Spartan 3A when you use DCI > termination for 100 differential lines as all the power dissipated will > be within the chip. The advantage of using external termination > resistors or LVDS devices is that the power is not dissipated within the > FPGA. > > > Ben Only the Spartan-3 offers DCI - not Spartan-3A, not even Spartan-3E. The DIFF_TERM is offered in the 3A and 3E but DCI is expected for the Spartan-3 base family only. Starting with the Virtex-2Pro (it appears, from an Austin Lesea response back in early 2004) the LVDS_DT uses "a true differential termination (a resistor) that is switched in between + and - inputs" which shouldn't take up *any* significant power. http://groups.google.com/group/comp.arch.fpga/msg/c0e735c3ecf07621?Article: 115234
Hi all, I was trying to reconfigure two circuits, I see that because of the interconnects/routing, the bitstream difference is wierd. Is there a way to over come this? Thanks in advance Mr.BArticle: 115235
> Well, it's polite enough, but look at that spelling... You're so old skool, Peter. JBArticle: 115236
On Feb 4, 4:04 pm, "jbnote" <jbn...@gmail.com> wrote: > > Well, it's polite enough, but look at that spelling... > > You're so old skool, Peter. > > JB Hey all, Lets not keep arguing abt the spellings and other stuffs in here. No offence JB!!!!!! Lets learn something. Anyways, I am sorry if I was disrespectful to anyone. Please let us know something about the routing details(If at all someone knew). Mr.BArticle: 115237
Yes I am, and proud of it :-) Somebody has to hold up the banner of this language, even if it takes an immigrant to do it ! Peter ============= On Feb 4, 2:04 pm, "jbnote" <jbn...@gmail.com> wrote: > > Well, it's polite enough, but look at that spelling... > > You're so old skool, Peter. > > JBArticle: 115238
On Feb 4, 2:16 pm, "Mr B" <bharadwaj...@gmail.com> wrote: > On Feb 4, 4:04 pm, "jbnote" <jbn...@gmail.com> wrote: > > > > Well, it's polite enough, but look at that spelling... As I mentioned before, the routing structure is the result of over a thousand man-years of development effort, not something that is easily explained on a newsgroup. But the real question had to do with partial reconfiguration, and I will dig up a few references to that. Peter ============== > > You're so old skool, Peter. > > > JB > > Hey all, > > Lets not keep arguing abt the spellings and other stuffs in here. No > offence JB!!!!!! Lets learn something. Anyways, I am sorry if I was > disrespectful to anyone. Please let us know something about the > routing details(If at all someone knew). > > Mr.BArticle: 115239
The overwhelming majority of configuration bits define the interconnect structure. Just look at the length of your bitstream, and compare it to the logic complexity. We used to say: "In FPGAs you pay for the flexibility of the interconnect, we throw in the logic for free..." Peter Alfke On Feb 4, 1:44 pm, "Mr B" <bharadwaj...@gmail.com> wrote: > Hi all, > > I was trying to reconfigure two circuits, I see that because of the > interconnects/routing, the bitstream difference is wierd. Is there a > way to over come this? > > Thanks in advance > > Mr.BArticle: 115240
Hello, What chip exactly are you looking at, and what information do you want to know ? I've looked in details at the virtex-2 XDL file format, and it's rather self-explanatory. You may want to read the chip's datasheets first to have a better grasp of the routing in the chips. Basically, the wires all have names which are locally defined with respect to a specific CLB. The pips in the .XDL are connections between locally-named wires. Let's take a simple example from a v2 chip: net "yCoordMultAdd/lutfunc<00>-E0" , outpin "yCoordMultAdd/lutfunc<16>-E0" Y , inpin "yCoordMultAdd/carry<02>" F3 , pip R28C45 Y0 -> OMUX3 , pip R29C46 F3_B0 -> F3_B_PINWIRE0 , pip R29C46 OMUX_SE3 -> F3_B0 , ; The wire has a fanout of 1. It starts from R28C45 Y0, goes through the first pip to R28C45 OMUX3. This wire goes to the R29C46 CLB site, where its name becomes OMUX_SE3, then is driven to F3_B0 by the last pip (the middle pip is actually a pseudo-pip which has no hardware meaning). As far as I know, there's no public document about the exact routing wires available on Xilinx chips, contrary to Altera. You can, however, derive such information from the xdl file, as Xilinx chips are pretty regularly layed out (contrary to Altera's there again). JBArticle: 115241
On Feb 4, 4:38 pm, "jbnote" <jbn...@gmail.com> wrote: > Hello, > > What chip exactly are you looking at, and what information do you want > to know ? > > I've looked in details at the virtex-2 XDL file format, and it's > rather self-explanatory. > You may want to read the chip's datasheets first to have a better > grasp of the routing in the chips. > > Basically, the wires all have names which are locally defined with > respect to a specific CLB. > The pips in the .XDL are connections between locally-named wires. > > Let's take a simple example from a v2 chip: > > net "yCoordMultAdd/lutfunc<00>-E0" , > outpin "yCoordMultAdd/lutfunc<16>-E0" Y , > inpin "yCoordMultAdd/carry<02>" F3 , > pip R28C45 Y0 -> OMUX3 , > pip R29C46 F3_B0 -> F3_B_PINWIRE0 , > pip R29C46 OMUX_SE3 -> F3_B0 , > ; > > The wire has a fanout of 1. It starts from R28C45 Y0, goes through the > first pip to R28C45 OMUX3. This wire goes to the R29C46 CLB site, > where its name becomes OMUX_SE3, then is driven to F3_B0 by the last > pip (the middle pip is actually a pseudo-pip which has no hardware > meaning). > > As far as I know, there's no public document about the exact routing > wires available on Xilinx chips, contrary to Altera. You can, however, > derive such information from the xdl file, as Xilinx chips are pretty > regularly layed out (contrary to Altera's there again). > > JB thanks a lot folks...... Mr.BArticle: 115242
I am a doing design.I am emulating FPGA.My problem is whenever i change one line of code(verilog) on top model i am getting getting most worst result.How to preserve the previous information.My time is wasting really like hell.I dont know how to end this design also.But functionally i proved the design is working.due to P& R result is changing.Really i am getting anger on the altera guys.Can you suggest me a solutionArticle: 115243
On Feb 5, 1:34 pm, "ram" <vsrpku...@rediffmail.com> wrote: > I am a doing design.I am emulating FPGA.My problem is whenever i > change one line of code(verilog) on top model i am getting getting > most worst result.How to preserve the previous information.My time is > wasting really like hell.I dont know how to end this design also.But > functionally i proved the design is working.due to P& R result is > changing.Really i am getting anger on the altera guys.Can you suggest > me a solution I am using cyclone 2 device with quartus 6.0 software.Article: 115244
ram wrote: >> Can you suggest >> me a solution I don't know about anyone else, but I don't have a clue what you are talking about, or how you expect anyone to be able to help you with such a lack of information. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 115245
On 30 Jan 2007 13:49:54 -0800, "Shant" <shantchandrakar@gmail.com> wrote: >Hi All, > >I am a Newbie and I am trying to load my C program on an FPGA using >through EDK 8.1i without using BSB (since it does not support multiple >processors). I am using Xilinx's ML310 development board for the same >and. I am using Jtag cable for connection. After downloading my >program on the FPGA and launching XMD I am getting the following >messages: > <...> Have you connected all OPB_clk and FSL_Clks? ZaraArticle: 115246
I'm attempting to use the CoreConnect BFM with a Verilog-based PLB peripheral (for a PowerPC-based design). I used the wizard to generate all of the VHDL parent and simulation files -- when I try to use the bfm_system project in XPS and run Modelsim, however, I run into a few issues. The first is that the unisims_ver library is not automatically being mapped at some point (even though it's in bfm_system.do: "vmap unisims_ver c:/xilinx/sim_iselib/unisims_ver/"), so it starts complaining about my instantiations of DCMs and various buffers (the primitives). I got around that problem by changing scripts/run.do to read: vsim -L unisims_ver bfm_system Now when I run it, Modelsim will compile the right Verilog files fine, but will stop with a strange error message. So far I've received: * "Unresolved defparam somewhere" (an incredibly unhelpful error message) * It will simply freeze at the end of loading the modules involved Is the BFM toolkit not designed for mixed-language designs? What are my options for debugging DMA transaction errors? Thanks, Kunal (FYI -- EDK 8.2 + latest patches/updates, Modelsim 6.0 SE)Article: 115247
On 2007-02-02, Klaus Falser <kfalser@IHATESPAMdurst.it> wrote: > I think you really found a bug in XST. > Switch FSM Extraction to "none" and it seems to work. Thanks, I'll recommend that to our students in the future. /AndreasArticle: 115248
ello guys.
I am trying to learn systemC in school. If anyone is not familiar with
it please check out the link.
Its an extension to the C++ library which helps to model concurrency
in hardware.
Im tryin to model a traffic light controller with 4 directions and
since the whole idea is to come up with a code which correctly models
event driven simulation, ive tried to use threads which respond to
certain events (similar to the sensitivity list in VHDL in case u know
VHDL).
And for some reason my output seems to be stuck somewhere..it hangs
and i have to manually kill the terminal by force closing it.
Heres the description of the problem:
I have four light controllers for traffic light in each direction
(North South(NS), South North(SN),West East(WE) and East West(EW).Each
of these controllers has 2 inputs and 1 output.Each light controller
receives input from a sensor(which magically senses cars) and the
light controller responds to this 'event' by sending a request to the
main controller thru the out port. The main controller processes its
request and send it its decision(decribed below) which it receives on
the 2nd in port.
As u might have guessed, the main controller's job is to issue
decisions to these local controllers( they shud have been called light
controllers i know :|) taking care of conflicting requests if there
are any. The main controller gives preference to the NS-SN direction
over the WE-EW direction in case of a conflict. I have tried to
introduce modularity in the code and hence I seperated the sensor from
the light controller(controller). When I build the file and then run
the executable, the whole terminal hangs and shows nothing ...
Heres the code:
include <main_controller.h>//main controller source file
#include <systemc.h>
main_controller::main_controller(sc_module_name name):sc_module(name)
{
SC_THREAD(check_requests);
result1.initialize(false);
result2.initialize(false);
result3.initialize(false);
result4.initialize(false);
SC_METHOD(issue_results);
dont_initialize();
sensitive << rqst_event;
}
void main_controller::check_requests()
{
for(;;){
req2 = request2->read();
req1 = request1->read();
req3 = request3->read();
req4 = request4->read();
cout<<" req1= "<<req1<<" at "<<sc_time_stamp()<<endl;
cout<<" req2= "<<req2<<" at "<<sc_time_stamp()<<endl;
cout<<" req3= "<<req3<<" at "<<sc_time_stamp()<<endl;
cout<<" req4= "<<req4<<" at "<<sc_time_stamp()<<endl;
cout<<endl;
if((req1 || req3) && (req2 || req4)) { // condition is only true for
conflicting reqs.
res1 = req1;
res3 = req3;
cout<< " MAIN CONTROLLER ALLOWS NS AND SN AT
"<<sc_time_stamp()<<endl;
res2 = false;
res4 = false;
rqst_event.notify();
wait(10,SC_SEC);
res1 = false;
res3 = false;
res2 = req2;
res4 = req4;
cout<< "---- MAIN CONTROLLER ALLOWS WE AND EW AT
"<<sc_time_stamp()<<endl;
rqst_event.notify();
wait(10,SC_SEC);
}
else if (!(req1 || req2 || req3 || req4)) {
res1 = false;
res2 = false;
res3 = false;
res4 = false;
rqst_event.notify();
wait(1,SC_SEC);
}
else {
res1 = req1;
res2 = req2;
res3 = req3;
res4 = req4;
rqst_event.notify();
wait(10,SC_SEC);
}
}
}
void main_controller::issue_results()
{
result1->write(res1);
result3->write(res2);
result2->write(res3);
result4->write(res4);
}
-------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------
// controller.h header file for light controller
#ifndef controller_h
#define controller_h
#include <systemc.h>
SC_MODULE(Controller){
//ports
sc_in<bool> self_sensor_req;//request from self sensor
sc_in<bool> controller_op;//decision taken by the main controller
sc_out<bool> send_req_main;//send req to main controller
bool light_value,sensor_value;
//events
sc_event sensor_event,light_event;
SC_HAS_PROCESS(Controller);
Controller(sc_module_name name);
void controller_response();//method to respond to the sensor event
void light_response();//method to respond to light event
void check_sensor();//thread which checks internal sensors
void check_result();//thread which monitors the signal light_value
};
#endif
-------------------------------------------------------------------------------------------------------
// controller.cc the light controller
#include "controller.h"
Controller::Controller(sc_module_name name)
:sc_module(name)
{
SC_METHOD(controller_response);
dont_initialize();
sensitive << sensor_event;
SC_METHOD(light_response);
dont_initialize();
sensitive << light_event;
SC_THREAD(check_sensor);
send_req_main.initialize(false);
SC_THREAD(check_result);
}
void Controller::check_sensor()
{
for (;;) { // infinite loop
sensor_value = self_sensor_req->read();
if (sensor_value){
cout<<name()<<" finds input at "<<sc_time_stamp()<<endl;// if self
sensor request
sensor_event.notify();//notify that there is an event which needs to
be responded
/*if light = true { //if light turned green by the method below then
wait(20,SC_SEC);//wait for 20 secs for the car(s) to pass
light = false; //turn the light red after that*/
wait(10,SC_SEC);//controller checks for sensor data every ten seconds
}
}
}
void Controller::check_result()
{
for(;;) {//infinite loop
wait(1,SC_SEC);//controller checks for main's output every second
light_value = controller_op->read();
cout<<" light value for "<<name()<<" at "<<sc_time_stamp()<< "
is "<<light_value<<endl;
if (light_value){//main controller asks it to turn the lights green
light_event.notify();//run a method to turn the light green in
response
}
}
}
void Controller::controller_response()
{
send_req_main = true;
cout <<name()<<" sends request to main controller at
"<<sc_time_stamp()<<endl;
}
void Controller::light_response()
{
cout << name() << " has its lights green at" <<sc_time_stamp()<<
endl;
}
#endif
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------
//header file for generator which "generates" traffic
#ifndef GENERATOR_H
#define GENERATOR_H
#include <systemc.h>//generator source file
SC_MODULE(Generator) {
sc_out<bool> sen_out;
SC_HAS_PROCESS(Generator);
Generator(sc_module_name name);
void generate_thread();
bool sensor_out;
};
#endif
-------------------------------------------------------------------------------------------------------
#include "generator.h" //generator source
Generator::Generator(sc_module_name name):sc_module(name),
sensor_out(false)
{
SC_THREAD(generate_thread);
sen_out.initialize(sensor_out);
}
void Generator::generate_thread()
{
int randomnr;
for(;;) {
randomnr = rand() % 50 + 11;
wait(randomnr,SC_SEC);
sensor_out = !sensor_out;
sen_out->write(sensor_out);
if (sensor_out = true)
cout <<"---- SENSOR "<<name()<<" HAS SENSED A CAR AT
"<<sc_time_stamp()<< endl;
}
}
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------
// testbench.cc which instantiates and then "connects" the objects to
each other
//and specifies simulation time
#include <systemc.h>
#include <controller.h>
#include <generator.h>
#include <main_controller.h>
int sc_main(int argc, char **argv)
{
srand(time(NULL));
// create instances of sensor generator modules for each
direction
Generator gen_NS("Generator_NS");
Generator gen_SN("Generator_SN");
Generator gen_WE("Generator_WE");
Generator gen_EW("Generator_EW");
// create intances of controller modules
Controller c_NS("Controller_NS"); //name and pointer to
sensor_values
Controller c_SN("Controller_SN");
Controller c_WE("Controller_WE");
Controller c_EW("Controller_EW");
main_controller M("main_controller");
// create channels between the controller instances and main
controller
sc_signal<bool> NS_main;
sc_signal<bool> SN_main;
sc_signal<bool> WE_main;
sc_signal<bool> EW_main;
sc_signal<bool> main_NS;
sc_signal<bool> main_SN;
sc_signal<bool> main_EW;
sc_signal<bool> main_WE;
// create channels between the sensor generator modules and the
corresponding controllers
sc_signal<bool> sen_NS;
sc_signal<bool> sen_SN;
sc_signal<bool> sen_WE;
sc_signal<bool> sen_EW;
// connect channels to ports of the modules instances
gen_NS(sen_NS);
gen_SN(sen_SN);
gen_WE(sen_WE);
gen_EW(sen_EW);
c_NS(sen_NS, main_NS, NS_main);
c_SN(sen_SN, main_SN, SN_main);
c_WE(sen_WE, main_WE, WE_main);
c_EW(sen_EW, main_EW, EW_main);
M(NS_main,WE_main,SN_main,EW_main,main_NS,main_WE,main_SN,main_EW);
// start simulation
sc_start(50, SC_SEC); //simulation time?
return 0;
}
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Heres the make file which i use:
# The PROGRAM variable should be the name of the final executable
PROGRAM = controller.x
# List your .cc-files here
SRCS = main_controller.cc controller.cc generator.cc testbench.cc
##################################
## DO NOT CHANGE ANYTHING BELOW ##
##################################
TARGET_ARCH = gcci386
LIBDIR = -L. -L.. -L$(SYSTEMC)/lib-$(TARGET_ARCH)
LIBS = -lsystemc -lm
LDFLAGS = -g
CC = g++
OPT = -O3
DEBUGFLAG = #-g
#OTHER = -Wall
#OTHER = -Wno-deprecated -fexceptions -frtti #-lstdc++#-Wall
OTHER = -Wno-deprecated
CFLAGS = $(DEBUGFLAG) $(OTHER)
EXE = $(PROGRAM)
# List all directories from where you include .h-files
INCDIR= -I. -I.. -I$(SYSTEMC)/include
OBJS = $(SRCS:.cc=.o)
## Variable that points to SystemC installation path
## version 2.1
SYSTEMC = /usr/include
.SUFFIXES: .cc .o .x
$(EXE): $(OBJS)
$(CC) $(LDFLAGS) $(INCDIR) $(LIBDIR) -o $(EXE) $(OBJS) $(LIBS)
.cc.o:
$(CC) -c $(CFLAGS) $(INCDIR) $< -o $@
clean:
rm -f $(OBJS) $(EXE) *~
#Makefile.deps:
# $(CC) $(CFLAGS) $(INCDIR) -M $(SRCS) >> Makefile.deps
#include Makefile.deps
Would be glad if anyone would point out something in the system which
will atleast make it run..may be theres a problem with the infinite
loop. Bt since threads are run only once, the only way to ensure that
they monitor the ports regularly at periodic time intervals is to
create an infinite loop. or maybe theres a problem with the make file
i dont really know.
I used the same make file which is used in our school lab where we
work with sun ray machines and modified it to reflect the x86 machine
im working with.
May be i didnt do it correctly in the make file.
Any help wud be sincerely appreciated.
Article: 115249Hi Friends, I would like to know more details on DFT,DFM.DFx and DFT tools used.. Please helpme to share some course materials,weblinks,CDs etc. Rgds Srinivas P_s_srinivas@hotmail.com P_s_srinivas@yahoo.co.in
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