From: Joel H. <jo...@ai...> - 2013-04-23 06:47:26
|
-------- Original Message -------- Subject: Re: Demon Core From: Ian Davis <id...@a1...> To: Joel Holdsworth <jo...@ai...> CC: Hi Joel, I've got a small site for the Logic Sniffer here: http://mygizmos.org/ols/index.html Please direct future contact to: dog...@my... The Dangerous Prototypes website also has a support forum for Logic Sniffer here: http://dangerousprototypes.com/forum/viewforum.php?f=23 The demon core was released under GPL2 so feel free to leverage it on those terms. Note the current Logic Sniffer fpga (XCV250E) is very full. Minor changes should be fine, but adding anything major will doubtless be a problem. It was designed for maximum logic density on Xilinx fpga's only. Many of the design choices won't port easily to other fpga vendors (like Altera). Now... not to dump on your idea, but you're going to face some challenges. A couple points... First, the various vendors want to differentiate themselves. Assuming similar advanced triggers, you should still expect differing numbers of terms, range checks, edge checks, states, etc... Mostly because of differing fpga flavors. Bigger parts = more features. Second, I based demon core on HP16550 style triggers. I doubt HP/Agilent cares about an low volume open source project. Commercial vendors however are viewed in an entirely different light. I have no idea what HP/Agilent patents the demon core infringes upon -- assuming any are still valid. Such concerns will give commercial vendors pause. In any case, I'll be happy to offer suggestions. Can't promise I'll have the time to develop new logic though. Cheers! -- Ian Joel Holdsworth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Dear Ian, > > Sorry to write to you on your work e-mail. I've been struggling to > find any other contact details for you online. > > I'm writing to you from the sigrok open source project, which is a > project about building an open source software suite to support all > kinds of signal analysis devices including logic analyzers and MSOs. > > We are in the early stages of exploring the possibility of building a > flexible/universal FPGA logic analyzer firmware. Our initial thoughts > are being assembled here: http://sigrok.org/wiki/Fpgalafw > > - From my review of prexisting projects, it seems like your Demon core > for the OLS is one of the more mature projects, so me may end up > starting with this as a base, but I didn't want to do anything without > first talking to you. > > I wondered if you would you like to participate in this effort in any > way? Just hearing your thoughts or advice would be helpful, or if > you'd like to get fully involved that would also be great. > > So let me know if you have any thoughts about this. > > Best Regards > Joel Holdsworth > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRdS40AAoJEIsWlGmq62IgWFYH/2l3UZoAkb4I402l2dgSc6S4 > 92xwBN31grVGdrZsOxGqY6PdMI65bAV6dfwRZbvnO8m3jkzhOt5Y+rgSj9Eh0Srz > 4fDTKJSuvPEd+O9SwnnpXJLW+zPgRDfG2Ru0tVdHHvFesHBrQraWU4Zsyr3Xh2eF > BBAzkDq5Jhyec7/wjNm6xpSrQimN7nt/UjWTvslz+35B7LJaYulv5NGrdEmArG8o > NecqW/iK4jP5KxZDWArx43cYCgGhRr+cGkBkx6w8Gi90EP5jQ9WjuDU5aEfdp9cX > rgAio6f4wI5qNzZWySQjHr3cYx7Sghh2aOyukG9eK6Xh6hXfzz0VZYpcp6jDMcE= > =Q2eF > -----END PGP SIGNATURE----- > > |
From: Iztok J. <izt...@gm...> - 2013-04-23 13:21:51
|
Hi, I am offering my help for writing RTL, bench code in Verilog. I have experience writing code which is portable across various vendors (Altera, Xilinx, Lattice should also work). I should be able to read the Wiki on the weekend. As far as I was looking into various FPGA based logic analyzers, the main issue is not the FPGA code but the various devices used to interface to USB. I also have some spare FPGA boards, but not really logic analyzers specific board, so I am not sure if they fit. Regards, Iztok Jeras On Tue, Apr 23, 2013 at 8:08 AM, Joel Holdsworth <jo...@ai...> wrote: > > > -------- Original Message -------- > Subject: Re: Demon Core > From: Ian Davis <id...@a1...> > To: Joel Holdsworth <jo...@ai...> > CC: > > > Hi Joel, > > I've got a small site for the Logic Sniffer here: > http://mygizmos.org/ols/index.html > Please direct future contact to: dog...@my... > > The Dangerous Prototypes website also has a support forum for Logic > Sniffer here: > http://dangerousprototypes.com/forum/viewforum.php?f=23 > > The demon core was released under GPL2 so feel free to leverage it on > those terms. > > Note the current Logic Sniffer fpga (XCV250E) is very full. Minor > changes should be fine, but adding anything major will doubtless be a > problem. It was designed for maximum logic density on Xilinx fpga's > only. Many of the design choices won't port easily to other fpga > vendors (like Altera). > > Now... not to dump on your idea, but you're going to face some > challenges. A couple points... > > First, the various vendors want to differentiate themselves. Assuming > similar advanced triggers, you should still expect differing numbers of > terms, range checks, edge checks, states, etc... Mostly because of > differing fpga flavors. Bigger parts = more features. > > Second, I based demon core on HP16550 style triggers. I doubt > HP/Agilent cares about an low volume open source project. Commercial > vendors however are viewed in an entirely different light. I have no > idea what HP/Agilent patents the demon core infringes upon -- assuming > any are still valid. Such concerns will give commercial vendors pause. > > In any case, I'll be happy to offer suggestions. Can't promise I'll > have the time to develop new logic though. > > Cheers! > -- Ian > > > > Joel Holdsworth wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Dear Ian, >> >> Sorry to write to you on your work e-mail. I've been struggling to >> find any other contact details for you online. >> >> I'm writing to you from the sigrok open source project, which is a >> project about building an open source software suite to support all >> kinds of signal analysis devices including logic analyzers and MSOs. >> >> We are in the early stages of exploring the possibility of building a >> flexible/universal FPGA logic analyzer firmware. Our initial thoughts >> are being assembled here: http://sigrok.org/wiki/Fpgalafw >> >> - From my review of prexisting projects, it seems like your Demon core >> for the OLS is one of the more mature projects, so me may end up >> starting with this as a base, but I didn't want to do anything without >> first talking to you. >> >> I wondered if you would you like to participate in this effort in any >> way? Just hearing your thoughts or advice would be helpful, or if >> you'd like to get fully involved that would also be great. >> >> So let me know if you have any thoughts about this. >> >> Best Regards >> Joel Holdsworth >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJRdS40AAoJEIsWlGmq62IgWFYH/2l3UZoAkb4I402l2dgSc6S4 >> 92xwBN31grVGdrZsOxGqY6PdMI65bAV6dfwRZbvnO8m3jkzhOt5Y+rgSj9Eh0Srz >> 4fDTKJSuvPEd+O9SwnnpXJLW+zPgRDfG2Ru0tVdHHvFesHBrQraWU4Zsyr3Xh2eF >> BBAzkDq5Jhyec7/wjNm6xpSrQimN7nt/UjWTvslz+35B7LJaYulv5NGrdEmArG8o >> NecqW/iK4jP5KxZDWArx43cYCgGhRr+cGkBkx6w8Gi90EP5jQ9WjuDU5aEfdp9cX >> rgAio6f4wI5qNzZWySQjHr3cYx7Sghh2aOyukG9eK6Xh6hXfzz0VZYpcp6jDMcE= >> =Q2eF >> -----END PGP SIGNATURE----- >> >> > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Peter S. <pe...@st...> - 2013-04-23 13:30:59
|
Iztok Jeras wrote: > As far as I was looking into various FPGA based logic analyzers, > the main issue is not the FPGA code but the various devices used > to interface to USB. Indeed. I know the USB protocol and the landscape of available controllers rather well, and I'd be happy to help with that part. //Peter |
From: Joel H. <jo...@ai...> - 2013-04-23 16:09:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter, Iztok Guys, that would be great. Please do note down your ideas on that wiki page, and let me know your thoughts. Joel On 23/04/13 14:30, Peter Stuge wrote: > Iztok Jeras wrote: >> As far as I was looking into various FPGA based logic analyzers, >> the main issue is not the FPGA code but the various devices used >> to interface to USB. > > Indeed. I know the USB protocol and the landscape of available > controllers rather well, and I'd be happy to help with that part. > > > //Peter > > ------------------------------------------------------------------------------ > > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring > service that delivers powerful full stack analytics. Optimize and > monitor your browser, app, & servers with just a few lines of code. > Try New Relic and get this awesome Nerd Life shirt! > http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ sigrok-devel > mailing list sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRdrJBAAoJEIsWlGmq62IgZl4IAJULVb9E/+yMnoNntRuTzpt6 iB5inEpCS7gn8VvmW2GQrF3+z8cTFR/ltRKxl3EYfx+a/e8pir+lfFTEHOv2kZxa Gc+kvvzfbGgUMXerNbS56INXlPTlNNESTRsUuwGGiZyvWg7XKbZ9Cdb3T7dizGZd R7K7O0lx9o7inqfAMQSJddJwjqbU7u2D1rAMGO7jXozjq7zXbpoZHpscTUSfDY9K zrXRhHtl1civytmyYrhOKFlnLKzibRyXptedoQkauWEJ7DPFiE3KVviBRj8a4mEb pJluFPTj6P5BNhkQLoAohfOCTpKD0mb07aiimnflBnH7576fRgJohsdVB4QC5jM= =J8mW -----END PGP SIGNATURE----- |
From: Bert V. <be...@bi...> - 2013-04-24 10:34:56
|
On 04/23/2013 03:21 PM, Iztok Jeras wrote: > Hi, > > I am offering my help for writing RTL, bench code in Verilog. I have > experience writing code which is portable across various vendors > (Altera, Xilinx, Lattice should also work). I should be able to read > the Wiki on the weekend. As far as I was looking into various FPGA > based logic analyzers, the main issue is not the FPGA code but the > various devices used to interface to USB. I also have some spare FPGA > boards, but not really logic analyzers specific board, so I am not > sure if they fit. Iztok, That's great to hear. As a way to get started with a portable source base, would porting the demon core be a good start? It's what we have already, after all. What would be the best way to structure a repository with different vendor targets, in your opinion? -- Bert Vermeulen be...@bi... email/xmpp |
From: Joel H. <jo...@ai...> - 2013-04-24 10:42:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/04/13 11:34, Bert Vermeulen wrote: > On 04/23/2013 03:21 PM, Iztok Jeras wrote: >> Hi, >> >> I am offering my help for writing RTL, bench code in Verilog. I >> have experience writing code which is portable across various >> vendors (Altera, Xilinx, Lattice should also work). I should be >> able to read the Wiki on the weekend. As far as I was looking >> into various FPGA based logic analyzers, the main issue is not >> the FPGA code but the various devices used to interface to USB. I >> also have some spare FPGA boards, but not really logic analyzers >> specific board, so I am not sure if they fit. > > Iztok, > > That's great to hear. As a way to get started with a portable > source base, would porting the demon core be a good start? It's > what we have already, after all. Right now I would say yes, we should just adopt the demon core and start hacking on it. Does someone want to import the SVN repo? I can do it if noone else wants to - but only as far as github. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRd7b9AAoJEIsWlGmq62Igq3wIAJ2gHOgC5RzLTTRYyvTusLAg pZDO2zgdAg6HDmyZ8+btc+OyRB6U9KeSprxlFP4wOI4LOMSVzeaRvBANbQjIdY6M ftz+/OXEhdcuvj/HszR/jDMVmxDIipQfsqwPuN+kbK1GQOFcWwBErBRuj7m92ju4 X8MUdabee0ZbrvMkHaIDEUsUzLZ7uNEbUBelG5bXHa3haZ0Vu1bIWYByvuxMRLY1 WY/Qka5I53fHWpAplGQtP6GrslI7EFH5nH4vgVTYiPa4jDVBbHSJIXqLBbq/4vEF 6SeLlhm0lSeelh+CtNwdtO/airgyM8kqFJ4ED7xBF76eLJm1E77BS4JbUMrnHqw= =+7mk -----END PGP SIGNATURE----- |
From: Peter S. <pe...@st...> - 2013-04-24 11:06:38
|
Joel Holdsworth wrote: > Does someone want to import the SVN repo? I have some experience with converting svn to git, and it's not completely trivial. What's the repo URL? //Peter |
From: Iztok J. <izt...@gm...> - 2013-04-24 11:08:17
|
Hi, On Wed, Apr 24, 2013 at 12:42 PM, Joel Holdsworth <jo...@ai...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 24/04/13 11:34, Bert Vermeulen wrote: >> On 04/23/2013 03:21 PM, Iztok Jeras wrote: >>> Hi, >>> >>> I am offering my help for writing RTL, bench code in Verilog. I >>> have experience writing code which is portable across various >>> vendors (Altera, Xilinx, Lattice should also work). I should be >>> able to read the Wiki on the weekend. As far as I was looking >>> into various FPGA based logic analyzers, the main issue is not >>> the FPGA code but the various devices used to interface to USB. I >>> also have some spare FPGA boards, but not really logic analyzers >>> specific board, so I am not sure if they fit. >> >> Iztok, >> >> That's great to hear. As a way to get started with a portable >> source base, would porting the demon core be a good start? It's >> what we have already, after all. I agree the demon core is a good start. I am already running: svn2git http://gadgetforge.gadgetfactory.net/svn/butterflylogic If there are no issues I will push it to Github, for now it seems slow (already running for 8min). > > Right now I would say yes, we should just adopt the demon core and > start hacking on it. Does someone want to import the SVN repo? I can > do it if noone else wants to - but only as far as github. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRd7b9AAoJEIsWlGmq62Igq3wIAJ2gHOgC5RzLTTRYyvTusLAg > pZDO2zgdAg6HDmyZ8+btc+OyRB6U9KeSprxlFP4wOI4LOMSVzeaRvBANbQjIdY6M > ftz+/OXEhdcuvj/HszR/jDMVmxDIipQfsqwPuN+kbK1GQOFcWwBErBRuj7m92ju4 > X8MUdabee0ZbrvMkHaIDEUsUzLZ7uNEbUBelG5bXHa3haZ0Vu1bIWYByvuxMRLY1 > WY/Qka5I53fHWpAplGQtP6GrslI7EFH5nH4vgVTYiPa4jDVBbHSJIXqLBbq/4vEF > 6SeLlhm0lSeelh+CtNwdtO/airgyM8kqFJ4ED7xBF76eLJm1E77BS4JbUMrnHqw= > =+7mk > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Peter S. <pe...@st...> - 2013-04-24 11:24:51
|
Iztok Jeras wrote: > I am already running: > svn2git http://gadgetforge.gadgetfactory.net/svn/butterflylogic Thanks for the URL. > If there are no issues I will push it to Github, for now it seems > slow (already running for 8min). Repository conversion is not a light affair. The output from conversion needs to quite careful review, and quite likely the conversion needs to be repeated many times with small tweaks each time. Also prepare to run git filter-branch on the output repository, and finally the result should be: git push --mirror into an empty new bare repo. As I wrote, this is nothing that a script does automatically - unless of course it doesn't matter what the output looks like, but then a conversion isn't really needed at all. //Peter |
From: Iztok J. <izt...@gm...> - 2013-04-24 11:31:57
|
On Wed, Apr 24, 2013 at 1:24 PM, Peter Stuge <pe...@st...> wrote: > Iztok Jeras wrote: >> I am already running: >> svn2git http://gadgetforge.gadgetfactory.net/svn/butterflylogic > > Thanks for the URL. > > >> If there are no issues I will push it to Github, for now it seems >> slow (already running for 8min). > > Repository conversion is not a light affair. The output from > conversion needs to quite careful review, and quite likely the > conversion needs to be repeated many times with small tweaks each > time. Also prepare to run git filter-branch on the output repository, > and finally the result should be: git push --mirror into an empty new > bare repo. > > As I wrote, this is nothing that a script does automatically - unless > of course it doesn't matter what the output looks like, but then a > conversion isn't really needed at all. I have started the first step, but svn2git is still running (20min now). I will review the results and report. > > > //Peter > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Iztok J. <izt...@gm...> - 2013-04-24 11:53:23
|
Hi Regarding the Verilog source, I would start with the next steps: 1. convert the test scripts to bash or better Makefile 2. rerun the tests (simulation) 3. rerun Xilinx ISE build scripts 4. put RTL and simulation files into separate directories 5. review the code to find Xilinx specifics, for now only a memory, which can be written generically Regarding code portability, usually the platform specific code is for: - internal memories - PLL, other clocking related details, this is never portable - IO, if specific IO features are used - 3rd party IP, for example an external memory controller, this is related to IO I can generalize memories, here I have experience with Altera Quartus, Xilinx Vivado and Synplify (used but Lattice). The code will have to be organized into portable and non portable segments. Here portability depends on the FPGA vendor and the board feature set. Then for every board top level files are created containing the list of IOs. Inside top level modules, generic modules are instantiated, potentially with some device specific code added (PLL). All FPGA vendors have tools for Linux, and all tools support scripted build processes. So building a release can be automatized, to avoid human error. I usually only have issues while migrating to newer tool versions. I would also suggest using Verilog 2001, it is especially useful to avoid repetition in port lists. The latest Icarus Verilog and Verilator, as well as FPGA tools have full support for Verilog 2001 RTL. In my day job we are already experimenting with SystemVerilog. There is some progress in Icarus Verilog and Verilator, actually the biggest hindrance is Xilinx, which supports SystemVerilog only with Vivado, which is limited to series 7 devices, older devices will never be supported. Regards, Iztok Jeras On Wed, Apr 24, 2013 at 1:08 PM, Iztok Jeras <izt...@gm...> wrote: > Hi, > > On Wed, Apr 24, 2013 at 12:42 PM, Joel Holdsworth > <jo...@ai...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 24/04/13 11:34, Bert Vermeulen wrote: >>> On 04/23/2013 03:21 PM, Iztok Jeras wrote: >>>> Hi, >>>> >>>> I am offering my help for writing RTL, bench code in Verilog. I >>>> have experience writing code which is portable across various >>>> vendors (Altera, Xilinx, Lattice should also work). I should be >>>> able to read the Wiki on the weekend. As far as I was looking >>>> into various FPGA based logic analyzers, the main issue is not >>>> the FPGA code but the various devices used to interface to USB. I >>>> also have some spare FPGA boards, but not really logic analyzers >>>> specific board, so I am not sure if they fit. >>> >>> Iztok, >>> >>> That's great to hear. As a way to get started with a portable >>> source base, would porting the demon core be a good start? It's >>> what we have already, after all. > > I agree the demon core is a good start. I am already running: > svn2git http://gadgetforge.gadgetfactory.net/svn/butterflylogic > If there are no issues I will push it to Github, for now it seems slow > (already running for 8min). > >> >> Right now I would say yes, we should just adopt the demon core and >> start hacking on it. Does someone want to import the SVN repo? I can >> do it if noone else wants to - but only as far as github. >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJRd7b9AAoJEIsWlGmq62Igq3wIAJ2gHOgC5RzLTTRYyvTusLAg >> pZDO2zgdAg6HDmyZ8+btc+OyRB6U9KeSprxlFP4wOI4LOMSVzeaRvBANbQjIdY6M >> ftz+/OXEhdcuvj/HszR/jDMVmxDIipQfsqwPuN+kbK1GQOFcWwBErBRuj7m92ju4 >> X8MUdabee0ZbrvMkHaIDEUsUzLZ7uNEbUBelG5bXHa3haZ0Vu1bIWYByvuxMRLY1 >> WY/Qka5I53fHWpAplGQtP6GrslI7EFH5nH4vgVTYiPa4jDVBbHSJIXqLBbq/4vEF >> 6SeLlhm0lSeelh+CtNwdtO/airgyM8kqFJ4ED7xBF76eLJm1E77BS4JbUMrnHqw= >> =+7mk >> -----END PGP SIGNATURE----- >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> _______________________________________________ >> sigrok-devel mailing list >> sig...@li... >> https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Iztok J. <izt...@gm...> - 2013-04-24 12:17:03
|
SVN import updates: I used svn2git, since this is the tool suggested by Github. To install it on Ubuntu do: $ sudo apt-get install git-core git-svn ruby rubygems subversion $ sudo gem install svn2git To perform the import do: svn2git -v http://gadgetforge.gadgetfactory.net/svn/butterflylogic --username anonymous This is a verbose import for an anonymous user, press enter a few times to confirm the empty password, otherwise the process will stall. So now I have some progress, but the import is not done yet. Since my subversion knowledge is outdated, more of us should do the import and look at the results. Here is the documentation with some options which might be used to fix import issues. Maybe we could add a list of author fullname/email pairs instead of simple usernames used by SVN. https://github.com/nirvdrum/svn2git Regards, Iztok Jeras |
From: Joel H. <jo...@ai...> - 2013-04-24 14:08:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/04/13 13:16, Iztok Jeras wrote: > SVN import updates: > > I used svn2git, since this is the tool suggested by Github. To > install it on Ubuntu do: $ sudo apt-get install git-core git-svn > ruby rubygems subversion $ sudo gem install svn2git > > To perform the import do: svn2git -v > http://gadgetforge.gadgetfactory.net/svn/butterflylogic --username > anonymous This is a verbose import for an anonymous user, press > enter a few times to confirm the empty password, otherwise the > process will stall. > > So now I have some progress, but the import is not done yet. Since > my subversion knowledge is outdated, more of us should do the > import and look at the results. Here is the documentation with some > options which might be used to fix import issues. Maybe we could > add a list of author fullname/email pairs instead of simple > usernames used by SVN. https://github.com/nirvdrum/svn2git > > Regards, Iztok Jeras > Sounds like it's working for you. Though, why not use git-svn? Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRd+dAAAoJEIsWlGmq62IgrUQH/Rm+abgv0k7d+exwufINwAsr hw6WWfseH9N/5zE1iThYoeAg9HSBLTtKUM52HhuVU3af5r/av4Clpp/RSDQe6mLe 6eHUOiSykDhfDk5frAiUG/sORN0huQbfJD5kF04zh7Sw4dvahZ3KIaCW4iNnGTdL qud3HK0WIHFdRq05wmhK70gYezQXXWAmAj5WEm5vhcjulI7OPay8cS0/gUOWLk2h aFcQT954Ligztr5ioRxsnlFD5x2uUfpQurzEYP1s8s3DHxlQOXQkpvMlbKWxIlYm 1PYWaxMOYR88eKH5yZyMQRso5HjdgDOEsxO0z/KYm9gv4wBoPdZvLJCLRy1hzaw= =YMJm -----END PGP SIGNATURE----- |
From: Joel H. <jo...@ai...> - 2013-04-26 15:07:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How did your import work out in the end? I did one with git-svn: git svn clone --username anonymous http://gadgetforge.gadgetfactory.net/svn/butterflylogic/trunk/Verilog_Core/ I pushed it here: https://github.com/jhol/demon-core-import Does that help at all? Joel On 24/04/13 13:16, Iztok Jeras wrote: > SVN import updates: > > I used svn2git, since this is the tool suggested by Github. To > install it on Ubuntu do: $ sudo apt-get install git-core git-svn > ruby rubygems subversion $ sudo gem install svn2git > > To perform the import do: svn2git -v > http://gadgetforge.gadgetfactory.net/svn/butterflylogic --username > anonymous This is a verbose import for an anonymous user, press > enter a few times to confirm the empty password, otherwise the > process will stall. > > So now I have some progress, but the import is not done yet. Since > my subversion knowledge is outdated, more of us should do the > import and look at the results. Here is the documentation with some > options which might be used to fix import issues. Maybe we could > add a list of author fullname/email pairs instead of simple > usernames used by SVN. https://github.com/nirvdrum/svn2git > > Regards, Iztok Jeras > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRepgzAAoJEIsWlGmq62IgniUIAJ7I7djwlZy015zD86tLW9cM 9kCXG0yroyLNAxFgf6rQaNobE8kMMP1+cOrU+UbdgTj0TEEMSpn7ccoRUZWMSMuy gBSKOeTsPh1W48UxP0oaXOSa4VWiy0mn2iY5UF5LrtviWoWHPlmQ4bEYsynKUNnz iPKf8Gj0WLYN290w4cjI7ViE3FUSzAIkvmY81GsFrtn9PQ5jXqf+nyW1v3FoQEvk s7f8q8H/K+JOfCL+T22xrE5382Rqy1P1lPqqQPmo9OG2hvFFg5+sraeMTZuYASW+ nVJ2/kpo2WB2hGp+wc/xg/wzdLnyWq9A1d0IeKN6DA4QOYTCCB+7l9jM3vF2z90= =xATE -----END PGP SIGNATURE----- |
From: Peter S. <pe...@st...> - 2013-04-26 15:20:26
|
Joel Holdsworth wrote: > https://github.com/jhol/demon-core-import > > Does that help at all? This repo has five commits in one branch, while the git-svn-id of master HEAD says that there are at least 329 revisions in the SVN repo, so it seems that a whole lot of stuff is missing.. //Peter |
From: Joel H. <jo...@ai...> - 2013-04-26 15:28:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > This repo has five commits in one branch, while the git-svn-id of > master HEAD says that there are at least 329 revisions in the SVN > repo, so it seems that a whole lot of stuff is missing.. Yes this is an import of just the demon core verilog code. Nothing else. That's all we need, no? Of course more directories from the repository can be included by modifying the SVN import url. Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRep0VAAoJEIsWlGmq62IgE0oH/jEE/Qo8V3q5fhwNzBEyd5g9 PqQUjezu3VLyusnn/3FQF+2Wr3foiHTUVwKRJ9/2/d6Te65FQW1oSxix5rEreFnm KVL3roVjEM3PNDVqUG0qbALPZco9Y1d34lFKUfrAlK9BjQ6f0esz3aZ5XOt2zkbN JzB0UHg2w6akKLVokaDSXp+WbLKTNQoH2gmHfP11/IiWARp7N+Rzz4am0ssRmzU8 8R0/oribouPsVaZTU8VLbsnwykuMYDPdGKFdGf7SrkUXHn5xR0TAsnsAJhFMk3li uYKpafZOlfwML8f74zPVNPo5ptjLWmMz2jKezEg/YeYYNukJnO7cnxa7DFDMk2k= =Zlf6 -----END PGP SIGNATURE----- |
From: Peter S. <pe...@st...> - 2013-04-26 15:32:44
|
Joel Holdsworth wrote: > > This repo has five commits in one branch, while the git-svn-id of > > master HEAD says that there are at least 329 revisions in the SVN > > repo, so it seems that a whole lot of stuff is missing.. > > Yes this is an import of just the demon core verilog code. Nothing else. > > That's all we need, no? I don't know. Are there any branches? Are there any references between directories? I don't know the repository too well, it would need looking into, to know for sure. It's also odd that there are five commits but the last one is release 7, but that can of course be a problem at the source. //Peter |
From: Peter S. <pe...@st...> - 2013-04-26 15:47:16
|
Joel Holdsworth wrote: > Yes this is an import of just the demon core verilog code. Nothing else. It looks like they used CRLF line endings in some (all?) files, which is generally not how to do things in a git repo. As I said, a good conversion takes a bit of work, even for five commits. //Peter |
From: Joel H. <jo...@ai...> - 2013-04-26 17:06:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/04/13 16:47, Peter Stuge wrote: > Joel Holdsworth wrote: >> Yes this is an import of just the demon core verilog code. >> Nothing else. > > It looks like they used CRLF line endings in some (all?) files, > which is generally not how to do things in a git repo. > > As I said, a good conversion takes a bit of work, even for five > commits. > This is a verbatim dump of the whole repository: https://github.com/jhol/butterflylogic As others have pointed out, we should probably be building from a clean canvas rather than tidying up this mess. Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRerQEAAoJEIsWlGmq62IgoqMH/0qE0StEPpoU2zcGqIgs6+3A r4ztiX/t2Po0SOozt98L3DsuLpPWQ+XIn387pyE8Dqrm5DZB0ibYDpfJDHJij55y GOEpA5xdXqfOzvtXw1kzvDMwjr+E7kJKrG/BqnSW1uO+GbYglQOzJM30t/0DqBgv z5T6rPMeJuxmPUT8trQHiF66JDXq1Z4oKoUvJNnii2JWmIlMjtVa2982UezYS40h zpDuuGAEJ/UERB1nmYsuEc7CRJcAa23NZeEGT6gnFbXi5c6LEEVkj0XVi9kvrOLH QaiA5TrHcEgzTMB0M+6U3FbLk/0NA++tWcu8y9MFetBqriYWSGLuzeStiSFPoSE= =xMjD -----END PGP SIGNATURE----- |
From: Iztok J. <izt...@gm...> - 2013-04-27 22:18:21
|
I have created a fork of the Github repo and started working on the Verilog code: https://github.com/jeras/butterflylogic The first changes are: - separation of RTL and bench code into directories - replaced *.bat files with a Makefile I was able to run all tests (adv adv2 rle rle2 full divider), but I am not sure yet if they are passing, since there is no clear message at the end of the test. Regards, Iztok Jeras On Fri, Apr 26, 2013 at 7:06 PM, Joel Holdsworth <jo...@ai...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 26/04/13 16:47, Peter Stuge wrote: >> Joel Holdsworth wrote: >>> Yes this is an import of just the demon core verilog code. >>> Nothing else. >> >> It looks like they used CRLF line endings in some (all?) files, >> which is generally not how to do things in a git repo. >> >> As I said, a good conversion takes a bit of work, even for five >> commits. >> > > This is a verbatim dump of the whole repository: > https://github.com/jhol/butterflylogic > > As others have pointed out, we should probably be building from a > clean canvas rather than tidying up this mess. > > Joel > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRerQEAAoJEIsWlGmq62IgoqMH/0qE0StEPpoU2zcGqIgs6+3A > r4ztiX/t2Po0SOozt98L3DsuLpPWQ+XIn387pyE8Dqrm5DZB0ibYDpfJDHJij55y > GOEpA5xdXqfOzvtXw1kzvDMwjr+E7kJKrG/BqnSW1uO+GbYglQOzJM30t/0DqBgv > z5T6rPMeJuxmPUT8trQHiF66JDXq1Z4oKoUvJNnii2JWmIlMjtVa2982UezYS40h > zpDuuGAEJ/UERB1nmYsuEc7CRJcAa23NZeEGT6gnFbXi5c6LEEVkj0XVi9kvrOLH > QaiA5TrHcEgzTMB0M+6U3FbLk/0NA++tWcu8y9MFetBqriYWSGLuzeStiSFPoSE= > =xMjD > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Iztok J. <izt...@gm...> - 2013-04-30 06:13:38
|
Hi, I found other portability issues in the design, they will require modifications to most of the code. 1. reset The design is coded specifically for FPGA, where all FlipFlops power up with in the state zero. I am an ASIC developer so this bothers me. But the main issue is the reset signal for the logic is not connected at all, so there is no way to reset the design except power-up. If we would port the design to a board with a proper reset signal, and we would wish to use it, the RTL would have to be modified, so control logic uses the reset, while the data paths usually can work without reset. Currently many control signals are initialized to zero in the RTL, this is required for the simulation to work properly, but it prevents a proper tesr for the reset signal. The solution is to use a macro for the initialized value (`define INIT = '0) and for the reset test use an undefined value for initialization (`define INIT = 'x). 2. use of nonblocking assignment (=) for FlipFlops The correct assignment operator for FlipFlops is blocking (<=), many modern synthesis tools report errors here. I am not sure if this is an archaic coding style or it is due to conversion from VHDL, but it should be fixed. The problem is, it seems some tests rely it, and it will take me some time to understand why. The execution order in the simulator depends on the used operator, the unit delays (#1) in the combinatorial logic are probably there to force a certain execution order, but they should not be necessary. I also have issues with the coding style for registers, where the combinatorial input into the register is coded separately from the register itself, and the combinatorial logic is using approaches typical for sequential languages. This is very uncommon, but not actually a bug. Regards, Iztok Jeras |
From: Joel H. <jo...@ai...> - 2013-04-30 08:07:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Iztok, You've really got into this thing! It's awesome. I wanted to discuss with you where we should go from here... A lot of people on IRC are suggestion we should start with a fresh empty repo, and then progressively harvest code from the Demon core, rather than trying to get it into shape as it is. Do you think it's really worth trying to use the Demon core as our base? Maybe it would be better to start with a folder structure, and some makefiles and build from there. I'm guess I'm saying we should agree some plan of where to go from here. Do we need to do some more design work in the wiki? or can we start coding immediately. Should we start fresh or hack on the demon core? Is fpgalafw an acceptable name for the project? - if so when can Uwe set up project repos. I was going to get started on this myself after the release. But I don't want to end up duplicating effort with you. On the subject of folder structure, I've been thinking of something like this: http://sigrok.org/wiki/Fpgalafw#Project_Folder_Structure Might need some adjustment though. Joel On 30/04/13 07:13, Iztok Jeras wrote: > Hi, > > I found other portability issues in the design, they will require > modifications to most of the code. > > 1. reset The design is coded specifically for FPGA, where all > FlipFlops power up with in the state zero. I am an ASIC developer > so this bothers me. But the main issue is the reset signal for the > logic is not connected at all, so there is no way to reset the > design except power-up. If we would port the design to a board with > a proper reset signal, and we would wish to use it, the RTL would > have to be modified, so control logic uses the reset, while the > data paths usually can work without reset. Currently many control > signals are initialized to zero in the RTL, this is required for > the simulation to work properly, but it prevents a proper tesr for > the reset signal. The solution is to use a macro for the > initialized value (`define INIT = '0) and for the reset test use an > undefined value for initialization (`define INIT = 'x). > > 2. use of nonblocking assignment (=) for FlipFlops The correct > assignment operator for FlipFlops is blocking (<=), many modern > synthesis tools report errors here. I am not sure if this is an > archaic coding style or it is due to conversion from VHDL, but it > should be fixed. The problem is, it seems some tests rely it, and > it will take me some time to understand why. The execution order in > the simulator depends on the used operator, the unit delays (#1) in > the combinatorial logic are probably there to force a certain > execution order, but they should not be necessary. > > I also have issues with the coding style for registers, where the > combinatorial input into the register is coded separately from the > register itself, and the combinatorial logic is using approaches > typical for sequential languages. This is very uncommon, but not > actually a bug. > > Regards, Iztok Jeras > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRf3ueAAoJEIsWlGmq62IgLcQH/1x638m+PdUkRQ7CjdkXS1I3 8UQYpP/h6wk4nSlxehZ+eiiWwKCxITuIRSzyy+Gm7yWeCg/rPJhWzER2v2ybMHel KGtcp92woe6jGcfvjmayfEfL4rllMJKqFF4Czn7q4JsFJPhl/S27PB29r0yPilMK iiMnYgfpUQD567CylF7cbkcISvhiOnmZOxnpDadmjTtee5DVRn96z8ZvFGpQVvbk gibdl/0XDV7GFmphacUnQltxrTwStHoAqTFnGoqcDdBqhib9iCkUqWrJwXVl5He2 +WpsyHdCv63jJnUnVJK6ZuGsxj4kEQJJZeTwDuGsSQTPH3TDVyC6vCB4/rV3tww= =uxh6 -----END PGP SIGNATURE----- |
From: Iztok J. <izt...@gm...> - 2013-04-30 09:47:34
|
Hi Joel, On Tue, Apr 30, 2013 at 10:06 AM, Joel Holdsworth <jo...@ai...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi Iztok, > > You've really got into this thing! It's awesome. For me it makes sense to first understand the existing code, I usually do this by editing the code, doing some vectorization, cleanups, ... > > I wanted to discuss with you where we should go from here... > > A lot of people on IRC are suggestion we should start with a fresh > empty repo, and then progressively harvest code from the Demon core, > rather than trying to get it into shape as it is. > > Do you think it's really worth trying to use the Demon core as our > base? Maybe it would be better to start with a folder structure, and > some makefiles and build from there. I do not really care if we start from an empty repo, or if we just rename the existing master into a branch and repopulate the master afresh. The only difference is the download size of the repo. > > I'm guess I'm saying we should agree some plan of where to go from > here. Do we need to do some more design work in the wiki? or can we > start coding immediately. Should we start fresh or hack on the demon > core? Is fpgalafw an acceptable name for the project? - if so when can > Uwe set up project repos. There is no simple reserved name for the "FPGA bitstream" (FPGA configuration, sometimes firmware, sometimes hardware). It is common to have a CPU inside the FPGA, and the code executed by the CPU would be firmware. It is also possible that a LA board would contain both firmware (some CPU, maybe FX2 or PIC) and hardware FPGA bitstreams, so I propose the name "fpgalahw". > > I was going to get started on this myself after the release. But I > don't want to end up duplicating effort with you. I will first try to understand the current FPGA code, this will be my only focus. So if you wish to avoid duplication, avoid the "trunk/Verilog_Core" directory. Was your intention to work on the HDL (RTL and test code)? > > On the subject of folder structure, I've been thinking of something > like this: http://sigrok.org/wiki/Fpgalafw#Project_Folder_Structure > Might need some adjustment though. A common HDL project directory structure looks like this: - rtl (contains synthesizable Verilog code) - tbn ("Test BeNch", usually just "bench", contains non Synthesizable Verilog verification code) - sim (simulation scripts) - syn (FPGA synthesis project, this is present only for top projects, not for components) Each shared Verilog component (memory controller, run length encoder, trigger decoder, host interface (SPI, UART, FX2 FIFO bus, ...), ...) can have this structure. Each board can also have the same structure, since it contains a top level file with the boars specific IO ports, each board also needs some simulation files. The synthesis directory is only needed for the boards. > > Joel > Regards, Iztok Jeras > > On 30/04/13 07:13, Iztok Jeras wrote: >> Hi, >> >> I found other portability issues in the design, they will require >> modifications to most of the code. >> >> 1. reset The design is coded specifically for FPGA, where all >> FlipFlops power up with in the state zero. I am an ASIC developer >> so this bothers me. But the main issue is the reset signal for the >> logic is not connected at all, so there is no way to reset the >> design except power-up. If we would port the design to a board with >> a proper reset signal, and we would wish to use it, the RTL would >> have to be modified, so control logic uses the reset, while the >> data paths usually can work without reset. Currently many control >> signals are initialized to zero in the RTL, this is required for >> the simulation to work properly, but it prevents a proper tesr for >> the reset signal. The solution is to use a macro for the >> initialized value (`define INIT = '0) and for the reset test use an >> undefined value for initialization (`define INIT = 'x). >> >> 2. use of nonblocking assignment (=) for FlipFlops The correct >> assignment operator for FlipFlops is blocking (<=), many modern >> synthesis tools report errors here. I am not sure if this is an >> archaic coding style or it is due to conversion from VHDL, but it >> should be fixed. The problem is, it seems some tests rely it, and >> it will take me some time to understand why. The execution order in >> the simulator depends on the used operator, the unit delays (#1) in >> the combinatorial logic are probably there to force a certain >> execution order, but they should not be necessary. >> >> I also have issues with the coding style for registers, where the >> combinatorial input into the register is coded separately from the >> register itself, and the combinatorial logic is using approaches >> typical for sequential languages. This is very uncommon, but not >> actually a bug. >> >> Regards, Iztok Jeras >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRf3ueAAoJEIsWlGmq62IgLcQH/1x638m+PdUkRQ7CjdkXS1I3 > 8UQYpP/h6wk4nSlxehZ+eiiWwKCxITuIRSzyy+Gm7yWeCg/rPJhWzER2v2ybMHel > KGtcp92woe6jGcfvjmayfEfL4rllMJKqFF4Czn7q4JsFJPhl/S27PB29r0yPilMK > iiMnYgfpUQD567CylF7cbkcISvhiOnmZOxnpDadmjTtee5DVRn96z8ZvFGpQVvbk > gibdl/0XDV7GFmphacUnQltxrTwStHoAqTFnGoqcDdBqhib9iCkUqWrJwXVl5He2 > +WpsyHdCv63jJnUnVJK6ZuGsxj4kEQJJZeTwDuGsSQTPH3TDVyC6vCB4/rV3tww= > =uxh6 > -----END PGP SIGNATURE----- |
From: Bert V. <be...@bi...> - 2013-04-30 10:10:05
|
Guys, Please can you properly quote and edit your mails when replying? This has gotten terrible, and this thread is near unparsable. We're not quite at the LKML stage yet, where we just drop HTML mail and ignore people that top-post, but I certainly see the wisdom in it. thanks, -- Bert Vermeulen be...@bi... email/xmpp |
From: Iztok J. <izt...@gm...> - 2013-04-30 11:27:56
|
On Tue, Apr 30, 2013 at 12:09 PM, Bert Vermeulen <be...@bi...> wrote: > Guys, > > Please can you properly quote and edit your mails when replying? This has > gotten terrible, and this thread is near unparsable. We're not quite at the > LKML stage yet, where we just drop HTML mail and ignore people that > top-post, but I certainly see the wisdom in it. Sorry Bert, I am not good at replying inline, but I will try, otherwise I will start a new tread. > > thanks, > > > -- > Bert Vermeulen be...@bi... email/xmpp > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |