Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Cx programming language

cx-lang.org

Post reply on HN
Print view View original

1–10 of 49 posts

Re: The Cx programming language

#2

Post by eps »

In the example, shouldn't it be checking that stop bits are ones?

Does available() extract and discard the bit if one's available? Or does it act a flag that's reset upon reading? Why doesn't loop() extract stop bits then?

I mean, this is clearly aimed at a technical audience with embedded background, so the code should really match the specs, even if it's just an illustartive example :)

Re: The Cx programming language

#3

Post by MootWoop »

eps wrote: post #2

In the example, shouldn't it be checking that stop bits are ones? Does available() extract and discard the bit if one's available? Or does it act a flag that's reset upon reading? Why doesn't loop() extract stop bits then? I mean, this is clearly aimed at a technical audience with embedded background, so the code should really match the specs, even if it's just an illustartive example :)

Hi I'm the person who wrote this example. In fact you don't need to check that stop bits are ones because one is the default: when nothing is being written on the line, it is high all the time. This is why it's just a matter of convention (number of stop bits) rather than a specific pattern.

EDIT: available checks that data is available on a port. If the test is true, then you can read from the port; if you don't read from the port, this is equivalent to an implicit read and data is discarded.

Re: The Cx programming language

#4

Post by kw71 »

MootWoop wrote: post #3
eps wrote: post #2

In the example, shouldn't it be checking that stop bits are ones? Does available() extract and discard the bit if one's available? Or does it act a flag that's reset upon reading? Why doesn't loop() extract stop bits then? I mean, this is clearly aimed at a technical audience with embedded background, so the code should really match the specs, even if it's just an illustartive example :)

Hi I'm the person who wrote this example. In fact you don't need to check that stop bits are ones because one is the default: when nothing is being written on the line, it is high all the time. This is why it's just a matter of convention (number of stop bits) rather than a specific pattern. EDIT: available checks that data is available on a port. If the test is true, then you can read from the port; if you don't rea…

Hi. I think this UART can be made better. A typical hardware UART receiver is clocked at a multiple of the signalling rate (16x is common) and the pin is sampled according to the clock. During the middle of the bit period, marks on the bus affect a counter whose value is compared to a constant, the result of which indicates whether the majority of samples indicate a mark or a space. The result of this goes into the receive shift register. The samples from the beginning and the end of the bit period are discarded.

This mechanism allows for timing differences between either end, and some immunity to electrical noise.

Also, sampling and validating the stop bit(s) will reveal framing errors.

Re: The Cx programming language

#5

Post by niklasni1 »

Hard to tell from the site if the language is proprietary or if it's just the IDE they're flogging.

I have to say "what this needs is another proprietary component in the toolchain" is not something I've ever thought when working with FPGAs. Quite the contrary.

Re: The Cx programming language

#6

Post by MootWoop »

kw71 wrote: post #4
MootWoop wrote: post #3

Earlier quoted context omitted.

Hi I'm the person who wrote this example. In fact you don't need to check that stop bits are ones because one is the default: when nothing is being written on the line, it is high all the time. This is why it's just a matter of convention (number of stop bits) rather than a specific pattern. EDIT: available checks that data is available on a port. If the test is true, then you can read from the port; if you don't rea…

Hi. I think this UART can be made better. A typical hardware UART receiver is clocked at a multiple of the signalling rate (16x is common) and the pin is sampled according to the clock. During the middle of the bit period, marks on the bus affect a counter whose value is compared to a constant, the result of which indicates whether the majority of samples indicate a mark or a space. The result of this goes into the r…

Thank you for your insight and suggestions! This example is really a toy implementation to show what the Cx language looks like, so it is not really suited for a robust hardware core. With this example I put the emphasis on how easy it is to understand what the Cx code does, and UART is a good use case because it is small enough.

Re: The Cx programming language

#7

Post by MootWoop »

niklasni1 wrote: post #5

Hard to tell from the site if the language is proprietary or if it's just the IDE they're flogging. I have to say "what this needs is another proprietary component in the toolchain" is not something I've ever thought when working with FPGAs. Quite the contrary.

Hi I'm a co-founder of Synflow and author of the website. Sorry if this is not clear about what is open source or not.

To answer your question the language, compiler, and IDE are open source: https://github.com/synflow/ngDesign We're using Xtext to develop the language. The open source version includes everything you need to design with Cx and then generate VHDL code. We also have a proprietary version that adds a Verilog code generator, exporters to third-party tools, and a C-based simulator.

I agree that a lot of tools for FPGAs are much too proprietary, hopefully we're contributing to changing that. I wish we could make it all open source but we also have to make a living :-)

Re: The Cx programming language

#8

Post by runeks »

This looks pretty cool.

Would love to see a toy example of a double-SHA256 engine. Would be kind of cool if people could build their own Bitcoin mining ASIC, crowd fund it, and give everyone access to cheap Bitcoin mining ASICs.

Re: The Cx programming language

#9

Post by scott_wilson46 »

I can't help but feel that the VHDL that was written is a bit overly verbose. You could probably write something like:

  i_sm: process(clk, reset)
  begin
    if (reset) then
      state  
          if (data_valid = '1') then
            if (count  
          if (data_valid = '1') then
            if (count
which is not too dis-similar from the Cx example (I've missed a few things out like port/signal declerations, just wanted to show the guts of the code). The thing I like about VHDL/Verilog is that its easy to tell the exact port names, what the clk is, the name and type of reset, etc which is useful information for putting the block in the context of an overall system.

Re: The Cx programming language

#10

Post by MootWoop »

runeks wrote: post #8

This looks pretty cool. Would love to see a toy example of a double-SHA256 engine. Would be kind of cool if people could build their own Bitcoin mining ASIC, crowd fund it, and give everyone access to cheap Bitcoin mining ASICs.

Thanks!

You might be interested by my implementation of SHA-256 in Cx available on Github: https://github.com/synflow/sha-256 It is a toy example (I haven't implemented the pre-processing step), with an architecture that offers a good trade-off in terms of performance / area, so it's probably not the ideal implementation if you want a very highly-optimized ASIC, but it's still a good starting point.

Post reply on HN