03:54 <mindrunner> sorry to bother u again with that, but it is kind of weird... I an now using a secondary serial port (not through the FTDI), which behaves totally the same. i set the baud to 3M, the software part on the board is constantly sending a string with a newline at its end. on the other side, i am reading with pyserial and just printing the received string to stdout. after starting the python script, the first approx 400kb are fine, afterwards I am

03:54 <mindrunner> getting random errors. restarting the python script gives me another 400kb of good data then bad, this is reproducable. It kind of feels more like a fault on my conputer's side than on the fpga side. is anybody keen to reproduce that? i could provide code if you want.

03:55 <mindrunner> it seems like, i can read more good data, before the errors occur when the difference between baud-rate and real io-speed is lower.

03:56 <mindrunner> about 1M baud looks currently good. but I think if I read somehow delayed, it might corrupt as well then.

03:58 <mindrunner> is it expected behaviour that i am losing bytes if there is no flow control/fifo whatever? so what is the serial port good for then? is there anybody out there using it for a reliable data transfer?

05:19 <mindrunner> i think i can answer some of my questions by myself. if i do not read fast enough, there are buffer overflows and i am losing data, correct? my java application is using a seperated thread for getting the data out of the serial interface and another one for processing, which seems way more reliable.

05:19 <mindrunner> but there is nothing which can guarantee me that i am really reading all bytes, right?

07:48 <sb0> mindrunner, you can implement flow control inside your protocol.

07:48 <mindrunner> xonxoff?

07:49 <sb0> for example. or even something in-band (e.g. wait for acks for the commands/data you send).

07:51 <mindrunner> i am already doing this. still everything above 1Mbaud is totally unstable. also there is another performance issue. if i just download data from fpga to pc, i am at about 100kb/s. if i send data in between as well, the total speed drops to about half.

07:53 <mindrunner> my curent protocol sends a command to read out a page form nand, then receives 2112kilobyte of data (plus encoding overhead). as long as i stay with 1MBaud, it seems to be fine, but only reads with 50kb/s.

07:53 <mindrunner> if i send two commands before reading the page, it drops to 25kb/s

07:54 <sb0> that's with the cpu, right?

07:55 <mindrunner> lm32 core and default uart

07:55 <mindrunner> no FTDI serial connection

07:56 <sb0> consider how many interrupts per second 100kb/s is (according to what I said and repeated before), how many cycles the interrupt service routine takes, and what the CPU frequency is

07:56 <mindrunner> yep

07:57 <mindrunner> looks like i need to burn an i7 into this fpga 8)

07:57 <sb0> no, you just need a more efficient uart data transfer mechanism than 1 IRQ + CSR read per byte

07:58 <sb0> again, this uart was optimized for minimal fpga resource usage, not for performance

07:58 <mindrunner> understand

07:59 <sb0> or just remove the CPU altogether as Florent suggested

07:59 <mindrunner> but no cpu means, no software, means imlement everything in hw

08:00 <sb0> you can maybe offload a lot of the handling to the PC

08:00 <sb0> make the fpga design as dumb as possible, but fast

08:02 <sb0> if you write a polling UART driver, what throughput can you expect?

08:02 <mindrunner> sort of having only the serial communication and a driver for the io pins in the fpga

08:02 <sb0> keeping the CPU?

08:02 <sb0> but not using the IRQs

08:02 <mindrunner> i dont know

08:02 <sb0> well, figure that out. that will help you.

08:03 <sb0> write the rough algorithm and estimate how many cpu cycles it'll take per byte

08:04 <mindrunner> ill try, tanks :)

08:04 <mindrunner> *h

08:10 <mindrunner> so I need to replace UART() class for this, dont I?

08:10 <sb0> no, keep the same uart, change the software

08:11 <sb0> but before you do that, estimate the throughput you can expect and decide if that's good enough for you or if you need a bigger boat

08:13 <mindrunner> hmm, sounds like a long weekend :/

08:14 <sb0> if you don't do that you'll keep making crappy designs and not understand why

08:18 <mindrunner> coming from a pure software background makes this soo hard to understand

08:19 <sb0> what kind of software were you writing that never required you to estimate how much time certain instructions were taking?

08:22 <mindrunner> that is not what i mean. i feel really lost in all this. reading the misoc/migen code is hard. (almost) no comments, (almost) no documentation. for someone who is not very experienced in hardware designs, this is really difficult

08:23 <sb0> well the uart data read process is: read CSR to determine if data is available, if it is, then read the data from another CSR and write to CSR to acknowledge the data reception and clear the data available flag

08:24 <sb0> "data" is just one byte here

08:26 <mindrunner> ok

08:36 <mindrunner> thats whats happening in uart_isr(), isnt it?

09:32 <larsc> .~.

10:55 <sb0> whitequark, http://pastebin.com/ryvEHD41

10:57 <whitequark> ft/hr

10:57 <whitequark> not /h

10:58 <whitequark> /h is... not sure what it is

10:58 <whitequark> planck constant

11:04 <sb0> ah, how did I miss thart

11:04 <sb0> *that

11:04 <sb0> yup, works :)

11:05 <whitequark> super useful

11:05 <whitequark> knows pretty much every constant and unit i needed so far

11:29 <cr1901_modern> sb0: The patch to fix ISE parsing for older chips is literally one line change. Do you still want me to send it and effectively decrease the SNR of the mailing list?

11:46 <sb0> you can send it to my email... sb @ the same domain without "lists."

11:47 <sb0> does that still work with s6 and k7?

11:47 <sb0> or do we have to remove the option when compiling for those newer chips? have you tested that?

11:55 <cr1901_modern> I'll test... it should have no effect on s6 and k7

11:58 <cr1901_modern> no errors on s6. Cannot test k7, as I do not have vivado

11:59 <sb0> xst/ise supports k7 as well

11:59 <sb0> and xst itself doesn't check the license, though maybe you don't have the devices installed.

12:02 <cr1901_modern> ERROR:Xst:1817 - Invalid target device 'xc7k325t'. It appears I do not.

12:02 <cr1901_modern> I completely forgot I could override the toolchain :P

12:02 <sb0> well, it should be fine if it works for s6 I guess

12:03 <cr1901_modern> As I understand it, 1. I shouldn't be using a Spartan-3, but hindsight is 20/20. 2. Since Spartan-3 is old, my theory is that Xilinx included an old parser for backwards compatibility.

12:04 <cr1901_modern> And they use the new parser by default for anything not s3

12:13 <cr1901_modern> My ISP is eating the emails I try to send using git send-email (I'm sending them to myself to test first). Debugging that now, then I'll send you the patch

12:14 <cr1901_modern> Makes me glad they withdrew their bid to take over another company

12:18 <whitequark> xilinx seems to just fork the entire toolchain every time they move to another chip series

12:18 <whitequark> bizarre. but i guess more tolerable of shitty engineering

12:23 <cr1901_modern> I also remember reading a convincing article that they also seem to be moving away completely in supporting hobbyists. Webpack's discontinuation isn't encouraging

12:30 <cr1901_modern> sb: Sent the patch.

12:31 <whitequark> hobbyists are not people you want to manufacture silicon for

12:33 <cr1901_modern> No kidding. No money :P.

12:37 <cr1901_modern> Hobbyists have to adapt to the changing market. And some of the stuff hobbyists do with current technology meant for customers ordering millions of chips astounds me.

12:39 <cr1901_modern> Like this person. I'll never be able to do BGA. I don't have the steady hand for it: http://www.reddit.com/r/electronics/comments/3184up/inspired_by_henriks_embedded_linux_system_i_made/

12:50 <whitequark> meh, BGA is not complex

12:50 <whitequark> just annoying because pbfree

12:52 <cr1901_modern> Do you have a station for it?

12:53 <whitequark> sure

12:57 <cr1901_modern> I can't afford one at the moment, but... I really should at least try BGA after I can afford one. In spite of my previous surface mount failures lmao

13:39 <sb0> cr1901_modern, how are they moving away completely from hobbyists?

13:39 <sb0> they even published an article about milkymist in their xcell journal, back in the days. even hackaday didn't do that.

13:41 <cr1901_modern> Xilinx? I don't remember the details of the article, other than it concerned me more than I already am- I'll see if I can find it. My immediate concern is they get rid of Webpack (free version), I won't be able to use their FPGAs. I can't afford a license for Xilinx's software!

13:42 <cr1901_modern> Webpack is already no longer updated- that's the prerequisite to phasing it out.

13:53 <cr1901_modern> I'm surprised hackaday didn't publish an article about milkymist. If Xilinx published an article, perhaps my concern is unfounded/there will be alternatives.

14:28 <whitequark> they stopped updating ISE, not WebPack (WebPack is not a product)

14:29 <whitequark> Vivado WebPack exists

14:29 <mumptai> nah, dropping free tool chains would be very unwise

14:30 <mumptai> students, many freelancers and opensource people would simeply walk away and never look back

15:02 <GitHub58> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vf6iM

15:02 <GitHub58> migen/master 472665b William D. Jones: Add a command line option (-use_new_parser yes) to Xilinx XST to force use of the newer parser for older FPGAs.

15:38 <GitHub108> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vf6HK

15:38 <GitHub108> artiq/master 110f7bc Sebastien Bourdeauducq: runtime: saner lwipopts

15:48 <travis-ci> m-labs/artiq#143 (master - 110f7bc : Sebastien Bourdeauducq): The build passed.

15:48 <travis-ci> Build details : http://travis-ci.org/m-labs/artiq/builds/60016572

16:47 <cr1901_modern> whitequark: Huh, so Vivado does have a free version... I did not know that. Well then... I retract my statements/I didn't do my research.

16:48 <cr1901_modern> mumptai: That's also true. I know one company that made a cool product- CircuitLab- that retracted its free version and ppl (including myself) won't use the product at all.

16:50 <mumptai> especially if the toolchain & ecosystem is more important than the specific FPGA type

16:59 <cr1901_modern> I remember reading recently that Lattice's FPGA bitstream was decoded, so a true open source toolchain from source code to programming the FPGA is on the horizon.

17:05 <whitequark> ahah no

17:05 <whitequark> PAR is... complex

17:05 <whitequark> massively

17:05 <whitequark> if you want it to make use of resources that is even slightly efficient

17:13 <larsc> just need a good multi variable solver ;)

17:13 <cr1901_modern> Wouldn't PAR be "max (min)imize" an objective function such as the number of "slices (assuming one slice consists of multiple 4LUTs and flip-flops)"?

17:13 <cr1901_modern> And knowing internally what the FPGA looks like XD

17:14 <cr1901_modern> number of slices used*

17:14 <whitequark> well, chemistry is basically just placing atoms together

17:14 <whitequark> simple, right

17:14 <larsc> physics is just applied mathematics

17:15 <larsc> the thing is, it is so hard that a lot of par tools don't even use it

17:15 <larsc> but rather just go for try and error

17:15 <larsc> 'simulated annealing'

17:15 <whitequark> annealing?

17:16 <whitequark> that's a strange way to name that

17:16 <larsc> that's the term for the method used

17:16 <larsc> http://en.wikipedia.org/wiki/Simulated_annealing

17:16 <whitequark> oh, so it *is* directly related to metallurgy

17:17 <whitequark> reminds me of that thing where ideal gas law was applied to roundworms

17:17 <cr1901_modern> Devil's in the details, right? Always in the details.

17:20 <larsc> there are opensource par tools, iirc, not necessarily perfect sure

17:20 <larsc> but that doesn't mean useless

17:21 <larsc> just means you won't be able to use as much resources

17:21 <cr1901_modern> I seem to recall that genetic algorithm has been used before for FPGAs, but it creates... weird layouts.

17:21 <larsc> or get lower clock speeds

19:20 <cr1901_modern> Anyone who can answer: I'm guessing "yes", but: am I setting myself for failure if I buy a cheap(er) Xilinix JTAG cable knockoff on Ebay?

20:17 <felix_> the 35 euro adapter i used maybe two years ago did work with the xilinx software