Menu
▾
▴
phdl-devel — PHDL General Development Discussion
This list is closed, nobody may subscribe to it.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(3) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(49) |
Nov
(47) |
Dec
(7) |
| 2013 |
Jan
(14) |
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(11) |
Feb
(1) |
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(4) |
Oct
(4) |
Nov
(2) |
Dec
(2) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <av...@ma...> - 2012-08-27 18:17:35
|
Hello, nice project but it lacks some features to use it in real life. 1. I don't found backannotation feature. How can i annotate back the changes made by compiler (i.e. assigned refdes'es) and PCB layout tool (i.e. pinswap)? 2. Traditional schematic editors are able to have only one schematic symbol for many components and annotate some properties to symbols dynamically via connectors to relational databases. Good examples are Cadence CIS or Mentor DxDatabook. Without such a feature i will sped time while creating numerous component definitions in PHDL. 3. How about more netlist formats? This really not big problem but... Please tell me about roadmap of this porject. If these featurea are not in plan then i will start new project based on VHDL... Thank you! |
|
From: Brad R. <bra...@gm...> - 2012-05-05 07:22:25
|
Great job, Richard! It seems like our nastiest bugs were those that have to do with improperly implemented equals methods, don't you think? Brad On Fri, May 4, 2012 at 4:37 PM, <byu...@us...> wrote: > Revision: 325 > http://phdl.svn.sourceforge.net/phdl/?rev=325&view=rev > Author: byupcbhdl > Date: 2012-05-04 22:37:03 +0000 (Fri, 04 May 2012) > Log Message: > ----------- > Found and removed the elusive bug in the NetListGenerator. I also fixed a > small bug inside the RefDesGenerator, where indices were being added to > RefDes's whether or not there was a RefPrefix. > > Modified Paths: > -------------- > trunk/projects/TestsOutput/InfoOutput/test1.info > trunk/projects/TestsOutput/NetListOutput/test1.asc > trunk/projects/TestsOutput/NetListOutput/test2.asc > trunk/projects/TestsOutput/NetListOutput/test3.asc > trunk/projects/TestsOutput/NetListOutput/test4.asc > trunk/projects/TestsOutput/RefDesOutput/test4.csv > trunk/projects/TestsOutput/RefDesOutput/test5.csv > trunk/src/phdl/generator/NetListGenerator.java > trunk/src/phdl/generator/RefDesGenerator.java > trunk/src/phdl/graph/Connection.java > trunk/src/phdl/graph/SubInstance.java > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > phdl-changes mailing list > phd...@li... > https://lists.sourceforge.net/lists/listinfo/phdl-changes > |
|
From: pedro <pet...@co...> - 2012-02-06 21:10:37
|
Guys Have you seen this. Very similar to JHDL but uses C++. I think we should contact this guy about our ASL for board design. Pete -----Original Message----- From: byu...@us... [mailto:byu...@us...] Sent: Monday, February 06, 2012 1:54 PM To: phd...@li... Subject: [phdl-changes] SF.net SVN: phdl:[309] papers/EDPSBrainstorm/document.tex Revision: 309 http://phdl.svn.sourceforge.net/phdl/?rev=309&view=rev Author: byupcbhdl Date: 2012-02-06 20:53:59 +0000 (Mon, 06 Feb 2012) Log Message: ----------- Updated brainstorm paper Modified Paths: -------------- papers/EDPSBrainstorm/document.tex This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ---------------------------------------------------------------------------- -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ phdl-changes mailing list phd...@li... https://lists.sourceforge.net/lists/listinfo/phdl-changes |
|
From: <pet...@co...> - 2012-01-04 16:21:54
|
Greetings from Albuquerque! I hope you guys had a restful holiday season. Zuly and I did some pretty heavy snow shoeing and x-country skiing in Colorado but we have recovered now. I am glad to see you are progressing on the new grammar. I have made a lot of progress on my simple PCIe board. It will have a spartan-6 fpga, power supply, ddr3 and some kind of data converters so it really requires hierarchy. Let me know when there is something I can start using to compile my design. I will be your beta tester. Pete ----- Original Message ----- From: bri...@us... To: phd...@li... Sent: Wednesday, January 4, 2012 8:46:39 AM Subject: [phdl-changes] SF.net SVN: phdl:[268] trunk/src/phdl Revision: 268 http://phdl.svn.sourceforge.net/phdl/?rev=268&view=rev Author: briching Date: 2012-01-04 15:46:39 +0000 (Wed, 04 Jan 2012) Log Message: ----------- Updates to grammars and data structures. Added index field to all classes that can be "arrayed" in phdl. Previously, string operations were performed on the name of the object to differentiate between indices. This broke some of the XML processing and iterative building techniques which is no longer needed by Eagle PCB anyways. Modified Paths: -------------- trunk/src/phdl/Compile.java trunk/src/phdl/Parser.java trunk/src/phdl/generator/EagleScriptGenerator.java trunk/src/phdl/generator/NetListGenerator.java trunk/src/phdl/generator/XMLGenerator.java trunk/src/phdl/generator/XMLtoDesignGenerator.java trunk/src/phdl/grammar/Phdl2.g trunk/src/phdl/grammar/Phdl2.tokens trunk/src/phdl/grammar/Phdl2Lexer.java trunk/src/phdl/grammar/Phdl2Parser.java trunk/src/phdl/grammar/PhdlLexer.java trunk/src/phdl/grammar/PhdlParser.java trunk/src/phdl/grammar/PhdlWalker2.g trunk/src/phdl/grammar/PhdlWalker2.java trunk/src/phdl/grammar/PhdlWalker2.tokens trunk/src/phdl/graph/Attributable.java trunk/src/phdl/graph/Design.java trunk/src/phdl/graph/Instance.java trunk/src/phdl/graph/Net.java trunk/src/phdl/graph/Pin.java This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ phdl-changes mailing list phd...@li... https://lists.sourceforge.net/lists/listinfo/phdl-changes |
|
From: pedro <pet...@co...> - 2012-01-03 00:53:10
|
http://en.wikipedia.org/wiki/PHDL |
|
From: pedro <pet...@co...> - 2011-12-23 00:22:17
|
Guys, I thought about a novel way to use your BOM output. Sometimes I like to put descriptive silkscreen text next to components, especially connectors. It looks like your BOM generator will pick up any attributes that I put on any device and create a new BOM column for that attribute. I could simply put a "silkscreen" attribute on any component and assign it a text value. That text would then show up in the BOM as instructions to the layout guy to be put next to the component. I don't think this requires any change to the way your compiler currently works. Happy Holidays Pete |
|
From: <pet...@co...> - 2011-10-06 04:33:31
|
Guys,
Maybe you already have this but it occurred to me that perhaps we should put in an option direction field in the pin statement of the device declaration.
I see two reasons for having this. First, we could use the direction of the pin to do some design rule checking. Second we could use the direction to generate VHDL or Verilog code for simulation.
Probably the DRC thing has real practicality. The second reason is of questionable utility but people often ask about it so maybe it is worth having just for completeness.
I'm thinking we could incorporate keywords in, out and bi into the language. The pin statement could look like this.
pin[3:0] bi byte_enable = {1, 2, 4, 7};
|
|
From: Wesley J. L. <wj...@ic...> - 2011-10-03 05:06:38
|
On 10/02/2011 08:12 AM, pedro wrote: > I think that means we should do some repo clean up before we go much > further. Maybe something like. > > Repo root > Branches > Tags > Trunk > Hardware > Proj1 > Proj2 > Software > Phdl (eclipse project for the phdl compiler) > Phdl_utils (eclipse project for the supporting > utilities like Xilix2PHDL) [...] > Wes, if you get a chance, please comment on repo reorganization. The de-facto standard organization in Subversion is: /trunk /tags /branches Where the content of /tags/<tag_name> and /branches/<branch_name> only ever corresponds to the layout of /trunk, never a subtree. This isn't the only way to do it (nor is it necessarily the technically best approach), but this structure provides the branching and tagging mechanism only, and isn't really part of the underlying project organization, so it's arguable less important than what lies below. Better tools (e.g. git) handle this part for you. As for project tree structure, it of course makes sense to split out the core, contrib tools, and example designs. There are lots of ways to go on the nitty gritty here. Is there a specific part of the organization that is in question? |
|
From: pedro <pet...@co...> - 2011-10-02 14:12:52
|
Guys, I moved the Xilinx CSV to PHDL converter program over to its own Eclipse project called phdl_utils at https://phdl.svn.sourceforge.net/svnroot/phdl/phdl_utils I also renamed the program to Xilinx2PHDL because we will need similar programs for Altera and Actel. I put it outside trunk because it looks to me that trunk is really the Eclipse project for the PHDL compiler. I think that means we should do some repo clean up before we go much further. Maybe something like. Repo root Branches Tags Trunk Hardware Proj1 Proj2 Software Phdl (eclipse project for the phdl compiler) Phdl_utils (eclipse project for the supporting utilities like Xilix2PHDL) Anyway, now I am up to speed on Eclipse so I will use it in place of Netbeans from now on so we are compatible. Wes, if you get a chance, please comment on repo reorganization. Pete |
|
From: pedro <pet...@co...> - 2011-10-01 00:49:57
|
Guys I see that you made some changes to the java code for the Xilinx CSV to PHDL converter utility, csv2phdl. I'm interested in working on it a little more because I need to make an FPGA board. I think I started on this thing using Netbeans but I want to use Eclipse if that is what you guys are using. Did you set up and commit an eclipse project to work on this program? Is there anything else I should know before I start hacking? Pete |
|
From: pedro <pet...@co...> - 2011-08-28 01:08:22
|
Brad I am up and running again with...\jars\phdl.jar in my CLASSPATH. I'll let you guys know if I can do incremental design using the .eco file. Pete -----Original Message----- From: bri...@us... [mailto:bri...@us...] Sent: Saturday, August 27, 2011 12:40 PM To: phd...@li... Subject: [phdl-changes] SF.net SVN: phdl:[203] trunk Revision: 203 http://phdl.svn.sourceforge.net/phdl/?rev=203&view=rev Author: briching Date: 2011-08-27 18:39:45 +0000 (Sat, 27 Aug 2011) Log Message: ----------- Added phdl.jar to jar folder. Point your classpath variable to this jar when testing out the compiler from the command line (and make sure to remove the /bin folder reference to the phdl project from your classpath as well) if you are having trouble staying current and building the project in eclipse. The root folder was also decluttered of old compiler output data, as all phdl projects now reside in the phdl folder. A problem was also fixed with the RefDesGenerator that prevented manual constraining of refDes's. Modified Paths: -------------- trunk/src/phdl/generator/RefDesGenerator.java Added Paths: ----------- trunk/jars/phdl.jar Removed Paths: ------------- trunk/digiclk.asc trunk/digiclk.bom trunk/digiclk.csv trunk/digiclk.info trunk/digiclk.scr trunk/digiclk.xml trunk/digiclk_bom.csv trunk/freq_cntr.asc trunk/freq_cntr.bom trunk/freq_cntr.csv trunk/full_adder.asc trunk/full_adder.bom trunk/full_adder.csv trunk/heartMon.asc trunk/heartMon.bom trunk/heartMon.csv trunk/heartMon.xml trunk/heartMon_bom.csv trunk/test.asc trunk/test.bom trunk/test.csv trunk/test.info trunk/test.scr trunk/test.xml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ---------------------------------------------------------------------------- -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ phdl-changes mailing list phd...@li... https://lists.sourceforge.net/lists/listinfo/phdl-changes |
|
From: pedro <pet...@co...> - 2011-08-27 17:19:29
|
Brad
Thanks for the help with this.
I suspect you are right that I am not running with the latest and greatest
executable. I tried two or three different ways to get the latest
executable of phdl.Compile() but I still get the same java null pointer
exception. I am spending a bit of time fiddling with Eclipse. I am never
sure if I have compiled the code or not since it "autocompiles" by default.
There is no "Build" button to hit. Eventually I want to know enough about
the Antlr and java code to support myself but right now I am just a user.
This brings me back to a previous suggestion I had. At this point doesn't
it make sense to just commit the executables? That way we don't have to
install and use Eclipse on each machine that we use. Installation would be:
checkout repo -> set CLASSPATH -> run phdl.Compile. I would automatically
get the new executable each time I update the repo.
You may object to this on a couple of grounds. First you may worry about
breaking the build and messing up the users. One way to avoid this is for
you guys to work on a branch and then merge when you have new features
working. I use branches a lot even when working alone on a VHDL design. I
think it might even be good practice at this point in a project (if you are
not already working that way).
The other thing that you might worry about is that it is not good style to
commit compiled executables. Remember we can delete the un-clean
executables from the repo when we have a solid installer.
What do you guys think?
Pete
From: Brad Riching [mailto:bra...@gm...]
Sent: Friday, August 26, 2011 8:50 PM
To: pedro
Subject: Re: eco problems for incremental design
Pete,
I did an SVN update on your latest commit and ran it on my end. This is the
output I got when I ran it without using the clean (-c) switch:
brad@P8H67-DESKTOP /cygdrive/d/work/phdl/projects/FMC_DAC/phdl
$ java phdl.Compile fmc_dac.phdl
Compiling...fmc_dac.phdl
File Exists!
********CHANGES MADE********
REMOVE NET VREF
ADD NET 1V8_SENSE
ADD NET DAC_VREF
ADD NET SAMP_CLK_IN
ADD NET ANALOG_OUT
ADD INSTANCE sma_samp_clk : SMA_CON P2
ADD INSTANCE sma_analog_out : SMA_CON P3
ADD INSTANCE output_balun : MABACT0039 T1
ADD INSTANCE analog_bal_resP : res_0603 R2
ADD INSTANCE analog_bal_resN : res_0603 R3
ADD INSTANCE vref_res : capnp_0603 C1
ADD INSTANCE IPTAT_res : res_0603 R4
ADD INSTANCE IRQ_PULLUP : res_0603 R5
ADD INSTANCE clk_term : res_0603 R6
ADD INSTANCE L1 : ELKE L1
ADD INSTANCE C3 : capnp_0603 C2
ADD INSTANCE C4 : capnp_0603 C3
ADD INSTANCE C5 : capnp_0603 C4
ADD INSTANCE C6 : capnp_0603 C5
ADD INSTANCE L2 : ELKE L2
ADD INSTANCE C7 : capnp_0603 C6
ADD INSTANCE C8 : capnp_0603 C7
ADD INSTANCE C9 : capnp_0603 C8
ADD INSTANCE C10 : capnp_0603 C9
ADD INSTANCE C11 : capnp_0603 C10
ADD INSTANCE C12 : capnp_0603 C11
ADD INSTANCE C13 : capnp_0603 C12
ADD INSTANCE C14 : capnp_0603 C13
ADD INSTANCE C15 : capnp_0603 C14
ADD INSTANCE C16 : capnp_0603 C15
ADD INSTANCE C17 : capnp_0603 C16
ADD INSTANCE C18 : capnp_0603 C17
ADD INSTANCE mounting_hole1 : mount_hole_125 MTG1
ADD INSTANCE mounting_hole2 : mount_hole_125 MTG2
ADD INSTANCE mounting_hole3 : mount_hole_125 MTG3
ADD INSTANCE mounting_hole4 : mount_hole_125 MTG4
ADD INSTANCE LDO : LT3022 U2
ADD INSTANCE C1 : capnp_1210 C18
ADD INSTANCE C2 : capnp_1210 C19
ADD INSTANCE R2 : res_0805 R7
ADD INSTANCE R3 : res_0805 R8
MODIFY ATTRIBUTE REFDES = ATTRIBUTE REFDES = R6
MODIFY PIN d[36] {D36} PIN d[36] {D36}
MODIFY PIN e[2] {E2} PIN e[2] {E2}
MODIFY PIN e[3] {E3} PIN e[3] {E3}
MODIFY PIN e[6] {E6} PIN e[6] {E6}
MODIFY PIN e[7] {E7} PIN e[7] {E7}
MODIFY PIN e[9] {E9} PIN e[9] {E9}
MODIFY PIN e[10] {E10} PIN e[10] {E10}
MODIFY PIN e[12] {E12} PIN e[12] {E12}
MODIFY PIN e[13] {E13} PIN e[13] {E13}
MODIFY PIN e[15] {E15} PIN e[15] {E15}
MODIFY PIN e[16] {E16} PIN e[16] {E16}
MODIFY PIN e[18] {E18} PIN e[18] {E18}
MODIFY PIN e[19] {E19} PIN e[19] {E19}
MODIFY PIN e[21] {E21} PIN e[21] {E21}
MODIFY PIN e[22] {E22} PIN e[22] {E22}
MODIFY PIN e[24] {E24} PIN e[24] {E24}
MODIFY PIN e[25] {E25} PIN e[25] {E25}
MODIFY PIN e[27] {E27} PIN e[27] {E27}
MODIFY PIN e[28] {E28} PIN e[28] {E28}
MODIFY PIN e[30] {E30} PIN e[30] {E30}
MODIFY PIN e[31] {E31} PIN e[31] {E31}
MODIFY PIN e[33] {E33} PIN e[33] {E33}
MODIFY PIN e[34] {E34} PIN e[34] {E34}
MODIFY PIN f[4] {F4} PIN f[4] {F4}
MODIFY PIN f[5] {F5} PIN f[5] {F5}
MODIFY PIN f[7] {F7} PIN f[7] {F7}
MODIFY PIN f[8] {F8} PIN f[8] {F8}
MODIFY PIN f[10] {F10} PIN f[10] {F10}
MODIFY PIN f[11] {F11} PIN f[11] {F11}
MODIFY PIN f[13] {F13} PIN f[13] {F13}
MODIFY PIN f[14] {F14} PIN f[14] {F14}
MODIFY PIN f[16] {F16} PIN f[16] {F16}
MODIFY PIN f[17] {F17} PIN f[17] {F17}
MODIFY PIN f[19] {F19} PIN f[19] {F19}
MODIFY PIN f[20] {F20} PIN f[20] {F20}
MODIFY PIN f[22] {F22} PIN f[22] {F22}
MODIFY PIN f[23] {F23} PIN f[23] {F23}
MODIFY PIN g[6] {G6} PIN g[6] {G6}
MODIFY PIN g[7] {G7} PIN g[7] {G7}
MODIFY PIN g[9] {G9} PIN g[9] {G9}
MODIFY PIN g[10] {G10} PIN g[10] {G10}
MODIFY PIN g[12] {G12} PIN g[12] {G12}
MODIFY PIN g[13] {G13} PIN g[13] {G13}
MODIFY PIN g[15] {G15} PIN g[15] {G15}
MODIFY PIN g[16] {G16} PIN g[16] {G16}
MODIFY PIN g[18] {G18} PIN g[18] {G18}
MODIFY PIN g[19] {G19} PIN g[19] {G19}
MODIFY PIN g[21] {G21} PIN g[21] {G21}
MODIFY PIN g[22] {G22} PIN g[22] {G22}
MODIFY PIN g[24] {G24} PIN g[24] {G24}
MODIFY PIN g[25] {G25} PIN g[25] {G25}
MODIFY PIN g[27] {G27} PIN g[27] {G27}
MODIFY PIN g[28] {G28} PIN g[28] {G28}
MODIFY PIN g[30] {G30} PIN g[30] {G30}
MODIFY PIN g[31] {G31} PIN g[31] {G31}
MODIFY PIN g[33] {G33} PIN g[33] {G33}
MODIFY PIN g[34] {G34} PIN g[34] {G34}
MODIFY PIN h[10] {H10} PIN h[10] {H10}
MODIFY PIN h[11] {H11} PIN h[11] {H11}
MODIFY PIN h[13] {H13} PIN h[13] {H13}
MODIFY PIN h[14] {H14} PIN h[14] {H14}
MODIFY PIN h[16] {H16} PIN h[16] {H16}
MODIFY PIN h[17] {H17} PIN h[17] {H17}
MODIFY PIN h[19] {H19} PIN h[19] {H19}
MODIFY PIN h[20] {H20} PIN h[20] {H20}
MODIFY PIN j[39] {J39} PIN j[39] {J39}
MODIFY PIN k[40] {K40} PIN k[40] {K40}
ADD PIN sig {1}
ADD PIN gnd[3] {5}
ADD PIN gnd[2] {4}
ADD PIN gnd[1] {3}
ADD PIN gnd[0] {2}
ADD PIN sig {1}
ADD PIN gnd[3] {5}
ADD PIN gnd[2] {4}
ADD PIN gnd[1] {3}
ADD PIN gnd[0] {2}
MODIFY PIN VREF {C14} PIN VREF {C14}
ADD PIN input {5}
ADD PIN gnd {4}
ADD PIN out_coupled {3}
ADD PIN out_thru {1}
ADD PIN in {1}
ADD PIN out {3}
ADD PIN gnd {2}
ADD PIN in {1}
ADD PIN out {3}
ADD PIN gnd {2}
ADD PIN pin1 {1}
ADD PIN pin1 {1}
ADD PIN pin1 {1}
ADD PIN pin1 {1}
ADD PIN NC[1] {1}
ADD PIN NC[2] {2}
ADD PIN NC[3] {8}
ADD PIN NC[4] {15}
ADD PIN NC[5] {16}
ADD PIN OUT[1] {3}
ADD PIN OUT[2] {4}
ADD PIN ADJ_SENSE {5}
ADD PIN AGND[1] {6}
ADD PIN AGND[2] {7}
ADD PIN SHDN_N {9}
ADD PIN PGND[1] {10}
ADD PIN PGND[2] {11}
ADD PIN IN[1] {12}
ADD PIN IN[2] {13}
ADD PIN IN[3] {14}
ADD PIN GND_PAD {17}
Wrote xml file: fmc_dac.xml
Wrote BoM file: fmc_dac_bom.csv
Wrote netlist file: fmc_dac.asc
Wrote info file: fmc_dac.info
WARNING: devices.phdl line 258:7 unused device declaration: 2x8_hdr
WARNING: devices.phdl line 64:7 unused device declaration: TC4-14+
WARNING: devices.phdl line 19:7 unused device declaration: capnp_0402
WARNING: devices.phdl line 156:7 unused device declaration: slide_switch
WARNING: devices.phdl line 126:7 unused device declaration: sy898533
WARNING: devices.phdl line 111:7 unused device declaration: tant_cap
WARNING: fmc_dac.phdl line 17:8 floating net: SPI_CS
WARNING: fmc_dac.phdl line 17:16 floating net: SPI_SCLK
WARNING: fmc_dac.phdl line 17:26 floating net: SPI_SDO
WARNING: fmc_dac.phdl line 17:35 floating net: SPI_SDI
WARNING: fmc_dac.phdl line 18:8 floating net: RESET
WARNING: fmc_dac.phdl line 19:8 floating net: SAMP_CLK_IN
Compile successful: fmc_dac.phdl
Compile Time: 220 ms
Then I ran it with the clean switch and got:
brad@P8H67-DESKTOP /cygdrive/d/work/phdl/projects/FMC_DAC/phdl
$ java phdl.Compile fmc_dac.phdl -c
Compiling...fmc_dac.phdl
********Initial Build*******
Wrote xml file: fmc_dac.xml
Wrote BoM file: fmc_dac_bom.csv
Wrote netlist file: fmc_dac.asc
Wrote info file: fmc_dac.info
WARNING: devices.phdl line 258:7 unused device declaration: 2x8_hdr
WARNING: devices.phdl line 64:7 unused device declaration: TC4-14+
WARNING: devices.phdl line 19:7 unused device declaration: capnp_0402
WARNING: devices.phdl line 156:7 unused device declaration: slide_switch
WARNING: devices.phdl line 126:7 unused device declaration: sy898533
WARNING: devices.phdl line 111:7 unused device declaration: tant_cap
WARNING: fmc_dac.phdl line 17:8 floating net: SPI_CS
WARNING: fmc_dac.phdl line 17:16 floating net: SPI_SCLK
WARNING: fmc_dac.phdl line 17:26 floating net: SPI_SDO
WARNING: fmc_dac.phdl line 17:35 floating net: SPI_SDI
WARNING: fmc_dac.phdl line 18:8 floating net: RESET
WARNING: fmc_dac.phdl line 19:8 floating net: SAMP_CLK_IN
Compile successful: fmc_dac.phdl
Compile Time: 109 ms
I looked at the line number of your stack trace inside NetListGenerator.
Line 85 is blank, which leads me to believe you may not be using the current
SVN commit. I believe Richard found a null pointer bug in the
NetListGenerator yesterday and he committed the changes. Would you double
check to see if you have the latest by right clicking your
NetListGenerator.java file, selecting "Team", and then selecting "Update to
Head" to make sure you are using the most current version? We've noticed
that there have been a few times Eclipse and SVN reports that we are
updated, when in fact we are using old versions of the files. An update to
head has always fixed the problem.
Let me know if this doesn't fix it, and we'll progress from there.
Brad
On Fri, Aug 26, 2011 at 6:52 PM, pedro <pet...@co...> wrote:
Brad
I have a more pressing problem now. When I compile I get the java null
pointer exception.
C:\Users\pedro\workspace\phdl\projects\FMC_DAC\phdl>java phdl.Compile
fmc_dac.phdl
Compiling...fmc_dac.phdl
java.lang.NullPointerException
at
phdl.generator.NetListGenerator.generate(NetListGenerator.java:85)
at phdl.generator.NetListGenerator.<init>(NetListGenerator.java:52)
at phdl.generator.Generator.<init>(Generator.java:52)
at phdl.Compile.main(Compile.java:241)
ERROR: ERROR: [Ljava.lang.StackTraceElement;@6443226
This occurs when I run your latest code against my latest design. I'm not
using this, each or combine in my design so I thought I was safe.
Do you get this error when your run against it?
My design is here:
https://phdl.svn.sourceforge.net/svnroot/phdl/trunk/projects/FMC_DAC/phdl
Don't worry about it over the weekend. Let me know next week.
Pete
From: Brad Riching [mailto:bra...@gm...]
Sent: Friday, August 26, 2011 2:25 PM
To: pet...@co...
Subject: Re: eco problems for incremental design
Pete,
It sounds as though you may have run into a situation like I experienced
with Eagle at the beginning of our first board (which is getting quoted for
manufacture now). I had to write a custom program within the Eagle
framework to allow me to save progress I made in the layout with each
iterative build of phdl. The program saved the current board layout as a
template file that I "recalled" with a brand new board and netlist of parts
each time I made a change in the phdl. The parts that weren't there from
the last build remained over on the side, while everything else got routed
from the template. That way i could pick up where I left off.
I want to understand how PADS handles it's compare and change routines so
that we can fix this. Let us know right away when you think you've made
some progress on tracking down the problem, even if it exists in PADS.
Since I don't have the same amount of "iterative building" on my end that
you have, you may need to send us the entire PADS project for us to
collaborate efficiently.
I will be checking my email frequently this weekend if you end up working on
it from home. Let us know right away if you need anything.
Brad
On Fri, Aug 26, 2011 at 1:50 PM, <pet...@co...> wrote:
Brad
I did a little test case in DxD instantiating 10 decoupling caps.
You are right. Each net is a list of segments so that most component pins
are listed twice.
I must have another problem.
One solution is to delete all the nets and read in the asc file anew.
Unfortunately, in PADS if you delete a net you lose all the design rules
associated with that net. I would have to start over setting up diff pairs
etc.
!PADS-POWERPCB-V9.0-MILS!
*PART*
C1 CAP_0603
C2 CAP_0603
C3 CAP_0603
C4 CAP_0603
C5 CAP_0603
C6 CAP_0603
C7 CAP_0603
C8 CAP_0603
C9 CAP_0603
C10 CAP_0603
*CONNECTION*
*SIGNAL* GND
C1.2 C2.2
C2.2 C3.2
C3.2 C4.2
C4.2 C5.2
C5.2 C6.2
C6.2 C7.2
C7.2 C8.2
C8.2 C9.2
C9.2 C10.2
*SIGNAL* 3V3
C1.1 C2.1
C2.1 C3.1
C3.1 C4.1
C4.1 C5.1
C5.1 C6.1
C6.1 C7.1
C7.1 C8.1
C8.1 C9.1
C9.1 C10.1
_____
From: "Brad Riching" <bra...@gm...>
To: "pedro" <pet...@co...>
Sent: Friday, August 26, 2011 9:12:40 AM
Subject: Re: eco problems for incremental design
Pete,
Since PADS is able to compare the netlist(s) in incremental builds with the
engineering change orders, try using the -c (clean) switch when you run the
compiler in between builds. This wipes all generated output files from the
compiler before generating new ones. Right now, anything that exists in the
*.csv file will be used to constrain refDes's in future builds. If you have
manually constrained the refDes's inside your source (I see that you have),
then I can imagine incremental builds presenting some problems without us
implementing more intelligence in compare routines inside of the compiler.
Try wiping the compiler output with that clean switch, and see if that
eliminates the problem for now. We haven't run into problems with this on
our end, but we have also let the compiler do all of the refDes assignments
in incremental builds (we haven't manually constrained them on the boards we
are currently working on).
Brad
On Fri, Aug 26, 2011 at 8:08 AM, pedro <pet...@co...> wrote:
Brad
Maybe you are right about the netlist being a list of segments. I will run
some experiments to see if that is true.
In any case there is something bad happening. I use an incremental approach
to entering designs. I like to add some parts, then look at them in layout.
Then I add more parts and so on. This should work the same whether we use
DxDesigner schematics or PHDL.
The process for pulling in netlist changes uses an .eco file. The eco file
is generated in PADS by comparing the current .pcb board design with the new
.asc file with the changes. The eco file contains a list of the changes in
parts and nets. Finally, you import the eco file to get the updates.
Again, I could be making some mistakes but I cannot get PADS to generate a
good eco from the new asc file. Let me work on this some more with simple
example designs so I can give you some guidance. I thought the problem came
from the repeated component pins but now it sounds like something else.
Please do nothing on this for now. I will narrow it down and get back to
you.
Have a great weekend.
Pete
From: Brad Riching [mailto:bra...@gm...]
Sent: Thursday, August 25, 2011 10:22 PM
To: pedro
Subject: Re: [phdl-devel] Frist p0st!
Pete,
Have you imported the netlist into PADS yet? We designed the compiler to
adhere to the output format contained in the *.asc netlist file from the
fmc_module PADS project currently in the drop box folder. That netlist file
is attached to this email for your reference. In it you will see that every
refDes (dot) pin is duplicated, except for the first and last one in every
*SIGNAL* block.
Because of this format, we thought the tools interpreted the a net list like
a bunch of line segments, each defined by a start and end point. (The
coordinates being references to the refDes and pin). So, every part will
appear twice, (except for the first and last on any given net.)
For example, if we have a net called "CLK250_BAL_P" that connects to R4.2,
R7.1 and U1.6, that net statement would look like this in the *.asc file:
*SIGNAL* CLK250_BAL_P
R4.2 R7.1
R7.1 U1.6
I ran your latest SVN commit of fmc_dac.phdl through the compiler (with a
few minor changes with the latest additions of "each" that eliminates the
keyword "this") and I was able to duplicate what you said, except that C18.1
on my side appears on the +3V3 net instead of the +1V8 net. In my netlist
file I see C18.1 is on the +3V3 net once (line 61), and C18.2 is on the GND
net twice (line 334 and 335).
It is possible we have misunderstood the way PADS expects the netlist file.
I have also attached the netlist from our compiler I have generated on my
end for your reference. You can send me yours if you like and I will
compare the two (so I can first track down the discrepancy on the C18.1 pin
connecting to the +3V3 supply if it should actually connect to +1V8.) Then
I will run your netlist through PADS first thing tomorrow morning.
Keep letting us know what we can do to help you and make improvements!
Brad
On Thu, Aug 25, 2011 at 8:04 PM, pedro <pet...@co...> wrote:
Guys,
I don't want to bother you too much but I found (what I think is) a bug in
the PADS netlist generator.
My design,
https://phdl.svn.sourceforge.net/svnroot/phdl/trunk/projects/FMC_DAC/phdl/fm
c_dac.phdl
generates the netlist file,
https://phdl.svn.sourceforge.net/svnroot/phdl/trunk/projects/FMC_DAC/phdl/fm
c_dac.asc
The netlist file contains duplicate listings of the decoupling caps. For
example, C18.1 is listed twice on the +1V8 supply and C18.2 is listed twice
on gnd.
On my board layout, I am getting pretty close to when I need an accurate
netlist because I am going to start defining the plane splits.
Please take a look if you get a chance. Maybe I am messing up somewhere in
my design.
Pete
-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...]
Sent: Thursday, May 19, 2011 9:23 PM
To: phd...@li...
Subject: [phdl-devel] Frist p0st!
Okay guys,
I made two lists, and mass subscribed you guys. I've added you all as
administrators on the lists, so you should have received notifications
for those already.
phdl-devel -- for our general development discussion; we can and should
do most of our development discussions here. Unlike some mailing lists,
we're not munging reply-to headers, as this is bad practice and leads to
a lot of trouble. So please either use "reply" to respond via
individual, private mail, or "reply all" to hit everybody involved in a
discussion (including the list itself).
phdl-changes -- automatically generated SVN commit notifications. You
can unsubscribe from this if it gets annoying, but sometimes it's useful
to get asynchronous notifications when changes are made.
While I was at it, I updated the project's SF trove classifications a
bit, and tweaked a few other minor settings.
----------------------------------------------------------------------------
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel
----------------------------------------------------------------------------
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel
|
|
From: pedro <pet...@co...> - 2011-08-26 02:04:58
|
Guys, I don't want to bother you too much but I found (what I think is) a bug in the PADS netlist generator. My design, https://phdl.svn.sourceforge.net/svnroot/phdl/trunk/projects/FMC_DAC/phdl/fm c_dac.phdl generates the netlist file, https://phdl.svn.sourceforge.net/svnroot/phdl/trunk/projects/FMC_DAC/phdl/fm c_dac.asc The netlist file contains duplicate listings of the decoupling caps. For example, C18.1 is listed twice on the +1V8 supply and C18.2 is listed twice on gnd. On my board layout, I am getting pretty close to when I need an accurate netlist because I am going to start defining the plane splits. Please take a look if you get a chance. Maybe I am messing up somewhere in my design. Pete -----Original Message----- From: Wesley J. Landaker [mailto:wj...@ic...] Sent: Thursday, May 19, 2011 9:23 PM To: phd...@li... Subject: [phdl-devel] Frist p0st! Okay guys, I made two lists, and mass subscribed you guys. I've added you all as administrators on the lists, so you should have received notifications for those already. phdl-devel -- for our general development discussion; we can and should do most of our development discussions here. Unlike some mailing lists, we're not munging reply-to headers, as this is bad practice and leads to a lot of trouble. So please either use "reply" to respond via individual, private mail, or "reply all" to hit everybody involved in a discussion (including the list itself). phdl-changes -- automatically generated SVN commit notifications. You can unsubscribe from this if it gets annoying, but sometimes it's useful to get asynchronous notifications when changes are made. While I was at it, I updated the project's SF trove classifications a bit, and tweaked a few other minor settings. ---------------------------------------------------------------------------- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ phdl-devel mailing list phd...@li... https://lists.sourceforge.net/lists/listinfo/phdl-devel |
|
From: pedro <pet...@co...> - 2011-08-21 14:20:28
|
Brad, Richard, I remember experimenting with the PHDL compiler before I went on vacation a month ago. I want to try it again on a new design but I cannot find the instructions that I used last time. I think we need to publish some kind of introduction, front and center, on the SourceForge site with instructions on how to install and run PHDL. Pete |
|
From: pedro <pet...@co...> - 2011-08-17 00:51:00
|
Guys One of the big advantages of PHDL is that you can easily target various layout tools. Already PHDL can target Eagle and PADS. Later I hope we can target Mentor Expedition, Cadence Allegro and gEDA. For our demo board perhaps we could do the layout in both tools. Brad is up to speed on Eagle and I have used PADS quite a lot. We could each do a layout in the respective tool and then decide which to actually build. I think this approach could save time because neither of us would have to learn a new layout tool at this time. How does that sound? Pete |
|
From: pedro <pet...@co...> - 2011-07-09 14:12:41
|
Guys, I ran into a Mentor applications engineer last week and we started talking about the PHDL thing. He mentioned an internal tool that Lucent developed in the 1990's, SPRUCE. I found only one reference to SPRUCE on someone's Linkedin.com resume. Pete |
|
From: pedro <pet...@co...> - 2011-06-27 01:36:41
|
Guys,
I updated my Xilinx .CSV to PHDL device declaration generator. Here is the
code it generates for a Virtex-6 784 pin device. Autogenerating this code
is important because you have to modify it each time you change the FPGA
pinout.
I still need to touch up the instantiation template generator part of the
code. That part is commented out now.
//PART TYPE = xc6vlx75t
//SPEED GRADE = -2
//PACKAGE = ff784
//INPUT FILE = fmcw_fpga_pad.csv
//Root Filename = fmcw_fpga
//Full Part Number = xc6vlx75t-2ff784
// Part declaration extracted from Xilinx fmcw_fpga_pad.csv
device fmcw_fpga is
refprefix = "U";
pkg_type = "ff784";
mfgr = "XILINX";
partNumber = "xc6vlx75t-2ff784";
begin
// User I/O pins.
pin adc_cal "Y22";
pin adc_caldly "T25";
pin adc_calrun "T24";
pin adc_dclk_rst_n "D11";
pin adc_dclk_rst_p "E12";
pin adc_dclki_n "AE10";
pin adc_dclki_p "AF10";
pin adc_dclkq_n "AE14";
pin adc_dclkq_p "AD13";
pin adc_ddrph "V24";
pin adc_des "W22";
pin[11:0] adc_di_n "J23,J27,AB7,AA10,A27,G16,J22,F12,G26,B28,E14,F24";
pin[11:0] adc_di_p "K24,J26,AA7,Y10,A26,H16,J21,G12,G27,B27,E13,E25";
pin[11:0] adc_did_n "Y9,D15,F17,K18,B13,D21,D12,F21,G21,B23,A25,J20";
pin[11:0] adc_did_p "W8,E15,G17,K17,C14,E20,D13,F20,H20,B22,A24,K19";
pin[11:0] adc_dq_n "C21,C11,C20,A22,E19,F25,K23,E27,A19,H15,E28,G24";
pin[11:0] adc_dq_p "B21,B11,C19,A21,D20,F26,K22,F27,A20,J16,D28,H24";
pin[11:0] adc_dqd_n "G9,D25,G19,H28,F19,E17,A12,B19,H18,D18,A16,J18";
pin[11:0] adc_dqd_p "G8,E24,H19,G28,E18,D17,A11,B18,G18,C18,A15,J17";
pin adc_ece_n "U24";
pin adc_fsr "T26";
pin adc_ndm "V23";
pin adc_ori_n "D23";
pin adc_ori_p "E23";
pin adc_orq_n "C28";
pin adc_orq_p "D27";
pin adc_pdi "U26";
pin adc_pdq "U23";
pin adc_rclk_n "C24";
pin adc_rclk_p "B24";
pin adc_sclk "P21";
pin adc_scs_n "R20";
pin adc_sdi "Y23";
pin adc_sdo "W23";
pin adc_tpm "P22";
pin[22:0] cfg_addr
"N25,N24,L25,P23,N23,N21,N20,P25,P26,M28,N28,L24,P27,P28,L27,M27,AF14,AB14,A
C14,AB13,N26,AA14,AH13";
pin[15:0] cfg_dq
"AH15,AH16,AG14,AF15,AD15,AA16,Y14,AA15,AE15,AD16,AB16,AG16,AF16,AD17,AE17,A
C15";
pin cfg_fcs_b "AA12";
pin cfg_foe_b "Y13";
pin cfg_fwe_b "AH14";
pin cfg_le_b "M26";
pin dac_cs_n "Y27";
pin[13:0] dac_d0_n "C8,F15,E10,B16,E7,L7,K10,J8,J10,H9,F9,K13,F10,H10";
pin[13:0] dac_d0_p "B8,F16,F11,C15,D7,K7,K9,J7,J11,H8,E8,J12,G11,H11";
pin[13:0] dac_d1_n "C9,C16,G7,G13,C13,E9,B17,C10,A14,K15,B7,J13,F14,A9";
pin[13:0] dac_d1_p
"B9,D16,F7,H14,B12,D8,A17,D10,B14,J15,A7,H13,G14,A10";
pin dac_dci_n "C23";
pin dac_dci_p "D22";
pin dac_dco_n "AC23";
pin dac_dco_p "AB23";
pin dac_irq "Y25";
pin dac_reset "Y24";
pin dac_sck "W26";
pin dac_sdio "W28";
pin dac_sdo "Y28";
pin dac_sync_in_n "M21";
pin dac_sync_in_p "M22";
pin dac_sync_out_n "L26";
pin dac_sync_out_p "K27";
pin io_clkin_n "AG12";
pin io_clkin_p "AH11";
pin[7:0] led "R27,W25,T27,V25,V28,U28,U27,W27";
pin[3:0] pci_exp_rxn "U4,R4,N4,L4";
pin[3:0] pci_exp_rxp "U3,R3,N3,L3";
pin pci_exp_sys_clk_n "P5";
pin pci_exp_sys_clk_p "P6";
pin pci_exp_sys_reset_n "R28";
pin[3:0] pci_exp_txn "V2,T2,P2,M2";
pin[3:0] pci_exp_txp "V1,T1,P1,M1";
pin sfp0_refclk_n "W3";
pin sfp0_refclk_p "W4";
pin sfp0_rxn "AH2";
pin sfp0_rxp "AH1";
pin sfp0_txn "AF2";
pin sfp0_txp "AF1";
pin sfp1_refclk_n "J3";
pin sfp1_refclk_p "J4";
pin sfp1_rxn "B2";
pin sfp1_rxp "B1";
pin sfp1_txn "F2";
pin sfp1_txp "F1";
// Power and dedicated FPGA pins.
pin AVDD_0 "N14";
pin AVSS_0 "N13";
pin CCLK_0 "AH6";
pin CSI_B_0 "AG6";
pin DIN_0 "H6";
pin DONE_0 "L6";
pin DOUT_BUSY_0 "AF6";
pin DXN_0 "T13";
pin DXP_0 "T14";
pin[169:0] GND
"A1,A18,A2,A28,A6,A8,AA1,AA18,AA2,AA28,AA5,AA8,AB15,AB25,AB3,AB5,AC1,AC12,AC
22,AC5,AC6,AD19,AD3,AD4,AD5,AD9,AE1,AE16,AE26,AE5,AE6,AF13,AF23,AF3,AF5,AG1,
AG10,AG20,AG5,AH17,AH27,AH3,AH5,AH7,B15,B25,B3,B4,B6,C1,C12,C22,C5,D19,D3,D5
,D9,E1,E16,E26,E5,E6,F13,F23,F3,F5,G1,G10,G2,G20,G5,H17,H27,H3,H4,H5,H7,J1,J
14,J2,J24,J5,K11,K21,K3,K5,K6,L1,L10,L12,L14,L16,L18,L28,L5,L8,M11,M13,M15,M
17,M25,M3,M5,M9,N1,N10,N12,N16,N18,N22,N5,N6,N8,P11,P15,P17,P19,P3,P7,P9,R1,
R10,R12,R16,R18,R26,R5,R6,R7,R8,T11,T15,T17,T19,T23,T3,T4,T7,T9,U1,U10,U12,U
14,U16,U18,U20,U5,U6,U7,U8,V11,V13,V15,V17,V27,V3,V5,V6,V7,V9,W1,W14,W2,W24,
W5,W6,Y11,Y21,Y3,Y5";
pin HSWAPEN_0 "N7";
pin INIT_B_0 "M6";
pin M0_0 "F6";
pin M1_0 "D6";
pin M2_0 "C6";
pin[9:0] MGTAVCC "AB4,AF4,AH4,D4,F4,K4,M4,P4,V4,Y4";
pin[8:0] MGTAVTT "AC2,AE2,AG2,C2,E2,L2,N2,R2,U2";
pin MGTAVTTRCAL_115 "A5";
pin MGTRREF_115 "B5";
pin[39:0] NC
"AA19,AA20,AA21,AB18,AB19,AB21,AC18,AC19,AC20,AC21,AD18,AD20,AD21,AD22,AE18,
AE19,AE20,AE22,AF17,AF19,AF20,AF21,AF22,AG17,AG18,AG19,AG21,AG22,AH18,AH19,A
H20,AH21,V19,V20,V21,W18,W21,Y18,Y19,Y20";
pin PROGRAM_B_0 "M7";
pin RDWR_B_0 "G6";
pin TCK_0 "AB6";
pin TDI_0 "AA6";
pin TDO_0 "Y7";
pin TMS_0 "Y6";
pin VBATT_0 "J6";
pin[12:0] VCCAUX "K20,K8,L19,M8,N19,P8,R19,T20,T8,U19,U9,V8,W20";
pin[40:0] VCCINT
"K12,K14,K16,L11,L13,L15,L17,L9,M10,M12,M14,M16,M18,N11,N15,N17,N9,P10,P12,P
16,P18,R11,R15,R17,R9,T10,T12,T16,T18,U11,U13,U15,U17,V10,V12,V14,V16,V18,W1
3,W15,W17";
pin[1:0] VCCO_0 "W7,Y8";
pin[4:0] VCCO_14 "R21,T28,U25,V22,Y26";
pin[4:0] VCCO_15 "K26,L23,M20,N27,P24";
pin[4:0] VCCO_16 "C27,D24,F28,G25,H22";
pin[4:0] VCCO_23 "AB20,AE21,AF18,AH22,W19";
pin[4:0] VCCO_24 "AA23,AC27,AD24,AF28,AG25";
pin[4:0] VCCO_25 "A23,B20,E21,F18,J19";
pin[4:0] VCCO_26 "A13,C17,D14,E11,G15";
pin[4:0] VCCO_34 "AA13,AC17,AD14,AG15,Y16";
pin[5:0] VCCO_35 "AB10,AC7,AE11,AF8,AH12,W9";
pin[4:0] VCCO_36 "B10,C7,F8,H12,J9";
pin VFS_0 "AD6";
pin VREFN_0 "P13";
pin VREFP_0 "R14";
// UNUSED I/O pins.
pin IO_L0N_16 "H21";
pin IO_L0N_GC_24 "AA27";
pin IO_L0N_GC_34 "AD12";
pin IO_L0P_16 "G22";
pin IO_L0P_GC_24 "AA26";
pin IO_L0P_GC_34 "AE13";
pin IO_L10N_MRCC_24 "AF25";
pin IO_L10N_MRCC_35 "AE7";
pin IO_L10P_MRCC_24 "AE25";
pin IO_L10P_MRCC_35 "AD7";
pin IO_L11N_SRCC_35 "AG11";
pin IO_L11P_SRCC_35 "AF11";
pin IO_L12N_D2_FS2_24 "AD26";
pin IO_L12N_SM5N_35 "AE8";
pin IO_L12N_VRP_14 "R25";
pin IO_L12P_D3_24 "AC26";
pin IO_L12P_SM5P_35 "AF7";
pin IO_L12P_VRN_14 "R24";
pin IO_L13N_D0_FS0_24 "AH25";
pin IO_L13N_SM6N_35 "AH8";
pin IO_L13P_D1_FS1_24 "AH26";
pin IO_L13P_SM6P_35 "AG9";
pin IO_L14N_VREF_14 "P20";
pin IO_L14N_VREF_35 "AF9";
pin IO_L14N_VREF_A24_34 "AC16";
pin IO_L14N_VREF_FOE_B_MOSI_24 "AF24";
pin IO_L14P_35 "AE9";
pin IO_L14P_FCS_B_24 "AE24";
pin IO_L15N_RS1_24 "AH24";
pin IO_L15N_SM7N_35 "AE12";
pin IO_L15P_FWE_B_24 "AG24";
pin IO_L15P_SM7P_35 "AF12";
pin IO_L16N_CSO_B_24 "AB24";
pin IO_L16N_VRP_35 "AG8";
pin IO_L16P_RS0_24 "AC24";
pin IO_L16P_VRN_35 "AG7";
pin IO_L17N_14 "U21";
pin IO_L17N_35 "AH10";
pin IO_L17N_A18_34 "AB17";
pin IO_L17N_VRP_24 "AG23";
pin IO_L17P_14 "U22";
pin IO_L17P_35 "AH9";
pin IO_L17P_VRN_24 "AH23";
pin IO_L18N_14 "R23";
pin IO_L18N_16 "C26";
pin IO_L18N_24 "AD23";
pin IO_L18N_A16_34 "Y15";
pin IO_L18P_14 "R22";
pin IO_L18P_16 "D26";
pin IO_L18P_24 "AE23";
pin IO_L18P_A17_34 "W16";
pin IO_L19N_14 "T22";
pin IO_L19N_24 "AA22";
pin IO_L19N_VRP_34 "AA17";
pin IO_L19P_14 "T21";
pin IO_L19P_24 "AB22";
pin IO_L19P_VRN_34 "Y17";
pin IO_L1N_15 "H26";
pin IO_L1N_GC_24 "AD27";
pin IO_L1N_GC_34 "AC13";
pin IO_L1P_15 "H25";
pin IO_L1P_GC_24 "AD28";
pin IO_L1P_GC_34 "AB12";
pin IO_L2N_16 "G23";
pin IO_L2N_A14_D30_34 "Y12";
pin IO_L2N_D14_24 "AB28";
pin IO_L2P_16 "H23";
pin IO_L2P_A15_D31_34 "W12";
pin IO_L2P_D15_24 "AC28";
pin IO_L3N_16 "C25";
pin IO_L3N_D12_24 "AF27";
pin IO_L3N_SM1N_35 "AD8";
pin IO_L3P_16 "B26";
pin IO_L3P_D13_24 "AG28";
pin IO_L3P_SM1P_35 "AC9";
pin IO_L4N_VREF_14 "V26";
pin IO_L4N_VREF_15 "M19";
pin IO_L4N_VREF_35 "AB9";
pin IO_L4N_VREF_A10_D26_34 "AG13";
pin IO_L4N_VREF_D10_24 "AH28";
pin IO_L4P_15 "L20";
pin IO_L4P_35 "AA9";
pin IO_L4P_D11_24 "AG27";
pin IO_L5N_16 "F22";
pin IO_L5N_D8_24 "AE27";
pin IO_L5N_SM10N_15 "J25";
pin IO_L5N_SM2N_35 "AD10";
pin IO_L5P_16 "E22";
pin IO_L5P_D9_24 "AE28";
pin IO_L5P_SM10P_15 "K25";
pin IO_L5P_SM2P_35 "AC10";
pin IO_L6N_D6_24 "AA25";
pin IO_L6N_SM11N_15 "M24";
pin IO_L6N_SM3N_35 "AB8";
pin IO_L6P_D7_24 "AA24";
pin IO_L6P_SM11P_15 "M23";
pin IO_L6P_SM3P_35 "AC8";
pin IO_L7N_D4_24 "AD25";
pin IO_L7N_SM12N_15 "K28";
pin IO_L7N_SM4N_35 "AC11";
pin IO_L7P_D5_24 "AC25";
pin IO_L7P_SM12P_15 "J28";
pin IO_L7P_SM4P_35 "AD11";
pin IO_L8N_SRCC_15 "L22";
pin IO_L8N_SRCC_24 "AB26";
pin IO_L8N_SRCC_35 "W10";
pin IO_L8P_SRCC_15 "L21";
pin IO_L8P_SRCC_24 "AB27";
pin IO_L8P_SRCC_35 "W11";
pin IO_L9N_MRCC_24 "AG26";
pin IO_L9N_MRCC_35 "AA11";
pin IO_L9P_MRCC_24 "AF26";
pin IO_L9P_MRCC_35 "AB11";
pin MGTREFCLK0N_114 "AA3";
pin MGTREFCLK0N_115 "T5";
pin MGTREFCLK0P_114 "AA4";
pin MGTREFCLK0P_115 "T6";
pin MGTREFCLK1N_116 "G3";
pin MGTREFCLK1P_116 "G4";
pin MGTRXN0_116 "E4";
pin MGTRXN1_114 "AG4";
pin MGTRXN1_116 "C4";
pin MGTRXN2_114 "AE4";
pin MGTRXN3_114 "AC4";
pin MGTRXN3_116 "A4";
pin MGTRXP0_116 "E3";
pin MGTRXP1_114 "AG3";
pin MGTRXP1_116 "C3";
pin MGTRXP2_114 "AE3";
pin MGTRXP3_114 "AC3";
pin MGTRXP3_116 "A3";
pin MGTTXN0_116 "K2";
pin MGTTXN1_114 "AD2";
pin MGTTXN1_116 "H2";
pin MGTTXN2_114 "AB2";
pin MGTTXN3_114 "Y2";
pin MGTTXN3_116 "D2";
pin MGTTXP0_116 "K1";
pin MGTTXP1_114 "AD1";
pin MGTTXP1_116 "H1";
pin MGTTXP2_114 "AB1";
pin MGTTXP3_114 "Y1";
pin MGTTXP3_116 "D1";
pin VN_0 "R13";
pin VP_0 "P14";
end;
//total pins found = 784
|
|
From: pedro <pet...@co...> - 2011-06-24 23:40:59
|
Guys, The fmc_module.phdl and associated files are looking really tight. I have another board design in progress. Because of the large number of large buses that board is disheartening to wire up. The board contains a medium sized FPGA but my script for generating PHDL device declarations is close to finished. Maybe we should enter the new board using the PHDL flow. Pete -----Original Message----- From: bri...@us... [mailto:bri...@us...] Sent: Friday, June 24, 2011 1:52 PM To: phd...@li... Subject: [phdl-changes] SF.net SVN: phdl:[94] trunk Revision: 94 http://phdl.svn.sourceforge.net/phdl/?rev=94&view=rev Author: briching Date: 2011-06-24 19:52:00 +0000 (Fri, 24 Jun 2011) Log Message: ----------- Added capability in the grammar for number lists. String literals and number lists can also wrap across lines now. The example fmc_module.phdl is ready for critiquing in the phdl folder. Modified Paths: -------------- trunk/phdl/fmc_module.dot trunk/phdl/fmc_module.phdl trunk/src/phdl/PhdlComp.java trunk/src/phdl/grammar/Phdl.g trunk/src/phdl/grammar/PhdlWalker.g trunk/src/phdl/parser/Indexable.java trunk/src/phdl/parser/InstanceAssignment.java trunk/src/phdl/parser/PinDeclaration.java trunk/xml/phdl.xml Added Paths: ----------- trunk/phdl/wrap.dot trunk/phdl/wrap.phdl This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ phdl-changes mailing list phd...@li... https://lists.sourceforge.net/lists/listinfo/phdl-changes |
|
From: pedro <pet...@co...> - 2011-06-24 23:19:03
|
Brad, I hope you get this email. Your problem with that path in svn could be that the tool deletes the folders each time it regenerates the tree. The problem is that svn puts metadata into special .svn subfolders. When a file tree is deleted those .svn folders are lost and svn cannot handle that. Some Xilinx and Actel tools do the same thing. If you can just regenerate the tree then the easiest thing is to just delete that part of the tree from the svn repo. Good luck. -----Original Message----- From: bri...@us... [mailto:bri...@us...] Sent: Friday, June 24, 2011 1:58 PM To: phd...@li... Subject: [phdl-changes] SF.net SVN: phdl:[95] trunk/src/phdl/parser Revision: 95 http://phdl.svn.sourceforge.net/phdl/?rev=95&view=rev Author: briching Date: 2011-06-24 19:57:38 +0000 (Fri, 24 Jun 2011) Log Message: ----------- I don't know why I have to keep manually deleting the derived ANTLR parser/lexer/walker files every time I want to commit a new version. Removed Paths: ------------- trunk/src/phdl/parser/PhdlLexer.java trunk/src/phdl/parser/PhdlParser.java trunk/src/phdl/parser/PhdlWalker.java This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ phdl-changes mailing list phd...@li... https://lists.sourceforge.net/lists/listinfo/phdl-changes |
|
From: Wesley J. L. <wj...@ic...> - 2011-05-31 01:43:45
|
On Friday, May 27, 2011 15:34:18 pedro wrote: > I've been putting in some effort on the csv2phdl utility. Remember the > idea is to use this utility to auto-generate the monster component > declarations and instantiation templates for FPGA. It has gone about as > far as possible without knowing the final syntax for PHDL. Please take > a look at the svn log and code here > https://pcbl.svn.sourceforge.net/svnroot/pcbl/trunk/utils/csv2phdl > > I'm unsure about the best way to move it from the above repository into > this project. I did create a new folder in this project repo here: > https://phdl.svn.sourceforge.net/svnroot/phdl/trunk/src/utils > > The csv2phdl code is in a NetBeans 7.0 project. If you want to run it > you probably have to re-point it to the one jar file it uses. I've imported it. I did it as a lump changeset rather than preserving all the history, but I left a pointer back to the pcbl repository in the commit message for reference. You might want to re-test it in the new location for a quick sanity check. Once all is well, you can move your future development to the phdl repository. |
|
From: pedro <pet...@co...> - 2011-05-27 21:34:28
|
Wes, I've been putting in some effort on the csv2phdl utility. Remember the idea is to use this utility to auto-generate the monster component declarations and instantiation templates for FPGA. It has gone about as far as possible without knowing the final syntax for PHDL. Please take a look at the svn log and code here https://pcbl.svn.sourceforge.net/svnroot/pcbl/trunk/utils/csv2phdl I'm unsure about the best way to move it from the above repository into this project. I did create a new folder in this project repo here: https://phdl.svn.sourceforge.net/svnroot/phdl/trunk/src/utils The csv2phdl code is in a NetBeans 7.0 project. If you want to run it you probably have to re-point it to the one jar file it uses. -----Original Message----- From: Wesley J. Landaker [mailto:wj...@ic...] Sent: Thursday, May 19, 2011 9:23 PM To: phd...@li... Subject: [phdl-devel] Frist p0st! Okay guys, I made two lists, and mass subscribed you guys. I've added you all as administrators on the lists, so you should have received notifications for those already. phdl-devel -- for our general development discussion; we can and should do most of our development discussions here. Unlike some mailing lists, we're not munging reply-to headers, as this is bad practice and leads to a lot of trouble. So please either use "reply" to respond via individual, private mail, or "reply all" to hit everybody involved in a discussion (including the list itself). phdl-changes -- automatically generated SVN commit notifications. You can unsubscribe from this if it gets annoying, but sometimes it's useful to get asynchronous notifications when changes are made. While I was at it, I updated the project's SF trove classifications a bit, and tweaked a few other minor settings. ---------------------------------------------------------------------------- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ phdl-devel mailing list phd...@li... https://lists.sourceforge.net/lists/listinfo/phdl-devel |
|
From: pedro <pet...@co...> - 2011-05-27 02:05:48
|
I added a folder for supporting utilities at https://phdl.svn.sourceforge.net/svnroot/phdl/trunk/src/utils I am almost ready to publish with a Xilinx .csv to PHDL converter program. If the above location is not suitable just move it where you want it. Thanks. |
|
From: Wesley J. L. <wj...@ic...> - 2011-05-20 04:12:00
|
I whipped up a simple PHDL logo and installed it on the site. The source (GIMP xcf) is pushed to subversion. |
|
From: Wesley J. L. <wj...@ic...> - 2011-05-20 03:43:20
|
Okay guys, I made two lists, and mass subscribed you guys. I've added you all as administrators on the lists, so you should have received notifications for those already. phdl-devel -- for our general development discussion; we can and should do most of our development discussions here. Unlike some mailing lists, we're not munging reply-to headers, as this is bad practice and leads to a lot of trouble. So please either use "reply" to respond via individual, private mail, or "reply all" to hit everybody involved in a discussion (including the list itself). phdl-changes -- automatically generated SVN commit notifications. You can unsubscribe from this if it gets annoying, but sometimes it's useful to get asynchronous notifications when changes are made. While I was at it, I updated the project's SF trove classifications a bit, and tweaked a few other minor settings. (I sent this e-mail once already, but it went out before I'd actually gotten everyone subscribed.) |
|
From: Wesley J. L. <wj...@ic...> - 2011-05-20 03:38:32
|
Okay guys, I made two lists, and mass subscribed you guys. I've added you all as administrators on the lists, so you should have received notifications for those already. phdl-devel -- for our general development discussion; we can and should do most of our development discussions here. Unlike some mailing lists, we're not munging reply-to headers, as this is bad practice and leads to a lot of trouble. So please either use "reply" to respond via individual, private mail, or "reply all" to hit everybody involved in a discussion (including the list itself). phdl-changes -- automatically generated SVN commit notifications. You can unsubscribe from this if it gets annoying, but sometimes it's useful to get asynchronous notifications when changes are made. While I was at it, I updated the project's SF trove classifications a bit, and tweaked a few other minor settings. |
7 messages has been excluded from this view by a project administrator.
